[FFmpeg-devel] grabbing from dv1394
Tommi Sakari Uimonen
Tue Jul 10 18:07:58 CEST 2007
>> Maybe I should also dig into the dvgrab code to see what it does
> That's why OpenSource is so great!
Ok, it seems that dvgrab uses IEEE1394Reader class , which runs in
separate thread and uses a vector of buffers as a ringbuffer (100 frames
by default) to store the captured frames. Dvgrab then reads frames from
the ringbuffer in another thread and writes to disk using write(2), the
filedescriptor is opened with:
fd = open( filename.c_str(), O_CREAT | O_TRUNC | O_RDWR | O_NONBLOCK, 0644
After processing the frame, dvgrab gives the frame pointer back to
IEEE1394Reader which then can use it to store new frame. The default of
100 frames in the ringbuffer has been enough, I remember doing grabbing
with buffer size 25 with my old 1.7GHz AthlonXP without buffer overruns.
So the main point I guess is the two separated threads, one to read the
frames from DV card as fast as possible, other to store them to disk.
In ffmpeg, the ringbuffer is done with mmap which I guess is faster to use
than vector of buffers, but I fail to see how the threads are handled if
any, since grepping 'thread' over the source tree does not give many hits.
Unfortunately the IEEE1394Reader is c++ so it's not so straightforward to
use the code in ffmpeg, but the idea of a separate thread for reading the
DV device would be appropriate. The single thread approach works for
encoding disk streams but not for realtime usage.
This text explains how the IEEE 1394 Reader class works.
The IEEE1394Reader object maintains a connection to a DV
camcorder. It reads DV frames from the camcorder and stores them
in a queue. The frames can then be retrieved from the buffer and
displayed, stored, or processed in other ways.
The IEEE1394Reader class supports asynchronous operation: it
starts a separate thread, which reads as fast as possible from the
ieee1394 interface card to make sure that no frames are
lost. Since the buffer can be configured to hold many frames, no
frames will be lost even if the disk access is temporarily slow.
There are two queues available in an IEEE1394Reader object. One
queue holds empty frames, the other holds frames filled with DV
content just read from the interface. During operation the reader
thread takes unused frames from the inFrames queue, fills them and
places them in the outFrame queue. The program can then take
frames from the outFrames queue, process them and finally put
them back in the inFrames queue.
More information about the ffmpeg-devel