[AG-TECH] sending vic pre-encoded video

[Christoph Willing]

On 12/02/2009, at 7:07 AM, Andrew Ford wrote:

> Hi Chris,
>
> If not taking video from a camera, what about a hardware 264  
> encoding card? I would imagine the latency could be lower - do you  
> think vic would be able to take video from one?


Andrew,

I thinks there would still be some programming effort required since  
(I'm guessing) it would probably be producing some raw h264 video  
stream rather than an RTP stream (much like the mpeg2 encoded HDV  
camera video which has to be wrapped as an RTP stream).

Do you have any particular candidate 264 encoding card(s) in mind?



> Also, what specifically would be required as far as code  
> integration? Here at RIT our primary goal is getting uncompressed  
> video working, and I'm willing to do some significant coding work if  
> necessary to get there. Could you clarify some of the differences in  
> the codebase between UCL and UQ?

The main difference would be that the UQ version is multithreaded, so  
incorporating that into the UCL code is probably the most significant  
piece of work. Bear in mind that this has so far only been applied to  
the Linux side of the UQ codebase - applying it to Windows & Mac  
(others?) so that it would be suitable for UCL would need to be worked  
out & tested too. I assume they would want code that applies to all  
platforms that they currently support.


chris



> 2009/2/8 Christoph Willing <c.willing at uq.edu.au>
>
> On 07/02/2009, at 1:44 AM, Gurcharan S. Khanna wrote:
>
> hi,
>
> i just wanted to clarify how AG vic works. it seems to want a
> raw digital stream to encode in h.261, h.264, or whatever. it
> does not accept a stream that's already encoded, like mpeg2,
> mpeg4, mjpeg, etc. is that correct?
>
> i understand that the AGDV for windows and the DVservices for
> linux do accept HDV (mpeg2) as part of those modules. are they
> the only add-ons that do so?
>
> anyone working on adding mp4 support for the HDV modules which
> currently support mp2?
>
>
> Gurcharan,
>
> The problem with doing anything with the firewire port mpeg2 streams  
> (like converting to mpeg4 etc.) is the inherent 1/2 to 1 second  
> latency incurred inside the camera when encoding the mpeg2 stream in  
> the first place. Any further processing we choose to perform (like  
> mpeg2 -> mpeg4 conversion) may cause even further latency.
>
> What we really need to be able to do is grab the camera video  
> _before_ its encoded into mpeg2 i.e. before any latency is built  
> into the signal. This signal is available on some cameras as a  
> 1920x1080 YUV type signal via an HDMI connector - hence the previous  
> talk about the Blackmagic Intensity HDMI capture card which can  
> capture this signal.
>
> Work on it this patchy - lack of a Linux driver is the main  
> stumbling block here. Some initial work by Doug with the Blackmagic  
> card on OSX indicates the single threaded nature of standard vic may  
> be a bottleneck preventing full frame rate at 1920x1080. Perhaps a  
> multithreaded version of vic (like the UQVislab HDV enabled vic)  
> would work at full frame rate but integrating that into the standard  
> vic code would require a lot of effort. That integration was always  
> planned but we ran out of time/budget. Its not clear who could  
> afford that effort at the moment.



Christoph Willing                       +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland