[FFmpeg-devel] grabbing from dv1394

[Tommi Sakari Uimonen]

Hello again!

>> Maybe I should also dig into the dvgrab code to see what it does
>> differently.
>>
> That's why OpenSource is so great!

Ok, it seems that dvgrab uses IEEE1394Reader class [1], 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.


Tommi

[1] http://www.dennedy.org/kinodox/classIEEE1394Reader.html


     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.