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. chris Christoph Willing +61 7 3365 8316 QCIF Access Grid Manager University of Queensland
