Actually I suspect for YUV input, we won't be able to input fast enough without buffering, I've actually tried an ioctl before with YUV frames, and it would miss a frame once in awhile until I used buffering.
I have been playing with the YUV input, and here's my observations ...
If I use the devices /dev/video16 --> /dev/video48, I can achieve full motion with all frames. I tested this my recording a known sequence of YUV frames. However, the audio remains a problem, as the sync will eventually go off, either leading or following the video depending on what other processing is occurring.
My thoughts are this:
Since I know the sample rate of the audio and the frame rate of the video, it would be somewhat trivial to grab a single YUV frame and the exact number of audio samples that would be associated with a single frame. At 48000Hz audio, for example, the math is easy to do.
So, I am attempting to read a YUV frame and read the correct number of audio samples, and then writing them back out. If I could ioctl()s to do that, then the application could maintain the sync internally by only reading and writing the correct audio samples for a single YUV frame.
Any thoughts?
Paul
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
