Re: [LAU] live video switching? WAS: Re: VJ / VeeJing software alternatives

(Must Remember To Reply To All On List!)

Not video switching, and if all your video sources are going to be consumer products it may be of no interest to you, but the BBC has done a fair amount of research and development into tapeless production on Linux over the years. Mainly multi-channel recording, using prosumer Blackmagic card giving up to 4x SD in/outs.

http://ingex.sourceforge.net/

Plus other stuff, some of which is online but not targeted for the general public, where BBC News is using Ubuntu boxes and the Blackmagic cards for recording archive. Quite a lot of house written software though and seems even the Blackmagic driver is their own...

Actually they used them for the Olympics so some info in an article here:
http://www.bbc.co.uk/blogs/internet/posts/Raven-File-Ingest-Olympics
(There is a Wiki out there with a lot more technical info though ;) )

> Date: Mon, 21 Jul 2014 17:46:20 -0700
> From: len@email-addr-hidden
> To: robin@email-addr-hidden
> CC: linux-audio-user@email-addr-hidden
> Subject: Re: [LAU] live video switching? WAS: Re: VJ / VeeJing software alternatives
>
> On Mon, 21 Jul 2014, Robin Gareus wrote:
>
> > On 07/21/2014 06:33 AM, Len Ovens wrote:
> >> [17678.621172] usb 3-7: new high-speed USB device number 8 using xhci_hcd
> >> [17678.634428] usb 3-7: New USB device found, idVendor=04a9, idProduct=3215
> >> [17678.634437] usb 3-7: New USB device strings: Mfr=1, Product=2,
> >> SerialNumber=0
> >> [17678.634442] usb 3-7: Product: Canon Digital Camera
> >> [17678.634446] usb 3-7: Manufacturer: Canon Inc.
> >
> > That's just the usb stack detecting a device and reading the IDs. It
> > does not load a driver to handle it.
>
> That was my point ... no driver. It doesn't advertise itself as a video
> device. That is the problem, the camera can do a number of things and look
> to the computer like a USB drive, ptp camera or something else. So there
> needs to be something other than v4l to deal with it... something that has
> enough user input to tell it that "right now I want to use this as a
> <whatever>." There is no way of knowing when the user plugs it into the
> USB port what they want to do. The computer assumes download pictures.
>
> >> Anything I can find suggests using a screen reader to get the live video
> >> into the computer.
> >
> > screen reader? that sounds odd. A Video-Loopback can work:
> > http://chdk.setepontos.com/index.php?topic=4672.0 suggests
> >
> > $ sudo modprobe vloopback
> > $ V4L_DEVNAME=/dev/video0 canon-capture
> > capture> start
> > capture> v4l on
>
> That is meant for DV. I don't have that. (I also don't seem to have the
> vloopback) The Camaras come with tethering SW and I can use entangle in
> Linux for the same thing. They all offer a preview mode which is video.
> The idea is to screen capture that part of the screen and feed it to
> video. It seems most of these things want to use an older kernel... that
> is they have not been maintained for some time. I get the idea that in
> times past a DV/firewire interface was the chosen method of connecting a
> camera to the computer. But the latest batch of cameras are now all USB2.0
> because everyone has them. Video streaming does not seem to be something
> that is easy to set up... not something Canon intends these DSLRs to be
> used for, so there seems to be know way of setting them up to connect to
> the computer as a "webcam".
>
> > It looks like the canon camera is not supported by the v4l2 driver.
>
> I think it is the camera that does not set itself up the right way.
> Preview mode creates video in any case. I do not know what the latency is
> internal to the camera itself, but the whole chain from camera sensor to
> screen in preview seems about 1/3 sec.
>
> > That way the audio was always in sync (thanks for firewire
> > iso-synchroneous streams). dvsource-jack has options to calibrate
> > latency, and align the A/V but it may drift when streaming over long
> > periods of time if the soundcard is not word-clock synced with the camera.
>
> There will be drift anyway with more than one camera, but if dvswitch
> starts frame grabbing fresh with each switch action it will remain very
> close. Add a bit of delay to the audio and the brain will sort things out
> just fine. It seems obvious to me that the video sources are synced using
> frame store techniques in DVswitch as memory is cheaper than extra cables
> and master sync generators. (and cameras with external sync in)
>
> --
> Len Ovens
> www.ovenwerks.net
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
                                               

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sun Jul 27 00:15:04 2014