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