[LAU] AV i/o hardware

Simon Wise simonzwise at gmail.com
Tue Nov 25 12:37:40 UTC 2014


On 25/11/14 16:46, Len Ovens wrote:
> On Tue, 25 Nov 2014, Simon Wise wrote:
>
>> "Expensive" was referring to their range (which probably include the same
>> chips etc) in the context of the DIY approach we are talking about here.
>
> I agree it is a bit pricey compared to what most DIY setups are. I am looking at
> what the SW I have tried can do and what we used in The TV station where I
> worked in the early 80s had in even on air, but not much different in production.
>
> We had basically two hard switchers that each had one push button for each
> source available in the station. At the right side was a T handle fader that
> faded from one switch output to the other. That fade could be verying amounts of
> each signal (fade to black or whatever) or could be a wipe (a moving
> pre-selected shaped key) or a chromakey (what it was called then). What I have
> seen in live stream SW has the switcher part, but not the fade or keying except
> being able to key in a box in a set place on the screen. The idea of a wipe,
> even timed so a physical fader is not needed, is not there. Maybe someone can
> suggest SW that has some of these things, but the only solution I saw was with
> HW. What SW does have, is the ability to sync unrelated video streams at the
> cost of added latency. We used to call it a frame storer.
>
> Unfortunately, the newer DSLRs don't seem to have a DV output to firewire as
> some of the old video cameras did. Maybe this is still more common than I know.
> However with the OPs comment about having remote students speak on the screen
> the cameras in question will likely be webcams of various quality (the $3 dollar
> store ones are surprisingly good if you add some light) then the SW switching
> and being able to add a second video box to the screen may be enough for what is
> needed. I think that any of the cameras I have (including the DSLR) video out to
> a video capture card are not going to look any better... though the DSLR does
> have a nicer zoom and can focus. Having worked in the video business, I have
> never been interested in family video "taping" and so do not have a video
> camera/recorder to play with. I have a young boy who may change that, he has
> already done some stop motion animation and finds it easier to tell a story that
> way than with words. However, for most of what he would do, recording to file(s)
> and then mixing/switching/fading/etc. in post production rather than real time
> is more likely.
>
> I meantioned the keyer on a card only in case something more than what was
> available in SW was wanted. I think it is still cheaper than a full HW keyer,
> but yes it costs more than most of us wants to pay (or can).

A need for live keying, wipes and alpha overlays over several camera sources ... 
and nowhere near enough money to buy a big enough vision mixer ... was the 
motivation for a Linux based software vision mixer I put together in 2006. It 
can all be done with several FLOSS solutions.

Live headshots of actors on stage talking meant DV and firewire was useless to 
us, like webcams there is considerable buffering in the transport, about 8 video 
frames in the case of DV.

A PCI capture card with 4 buses pretty much direct to the GPU solved that 
problem (like these blackmagic cards ... the biggest hardware cost in the 
project, but affordable for us at the time). Pd with GEM via v4l did all the 
openGL mixing and effects, a BFC2000 midi controller with motor drive faders and 
rotary encoders was the interface the operators saw ... at least 12 alpha layers 
were possible from 4 composite sources switched from 16 inputs with images, 
video playback, generated text etc to 4 DVI outputs, all with a tolerable 0.5 to 
1.5 frames delay between the cameras and the projected image (the cameras were 
not genlocked, hence the variable latency). It would have been possible to feed 
a stream as well, other Pd projects at the time did that, the streaming options 
have got better now and if web streaming was the goal then putting some of the 
system at least in a remote web server would be the way to go.

It would have required very very serious money to do any other way at the time.


Simon


More information about the Linux-audio-user mailing list