[FFmpeg-devel] grabbing from dv1394

Michel Bardiaux mbardiaux
Wed Jun 6 12:20:25 CEST 2007


Tommi Sakari Uimonen wrote:
>>> I got the dv1394 grabbing working with a patch from
>>> http://svn.pardus.org.tr/pardus/devel/applications/multimedia/ffmpeg/files/ffmpeg-dv1394.patch
>>>
>>> I grab with:
>>>
>>> ./ffmpeg -f dv1394 -i /dev/dv1394/0 -f avi -acodec copy -vcodec copy -y
>>> outfile.avi
> 
>> You should always post the *complete* output messages. In this case, it
>> would have told us the actual containers, codecs, sizes, ...
> 
> For first grabbing test, I mount my disk with -o remount,sync. The result 
> being that only 7 frames get written of about 30 seconds of running.
> 
> tuimonen at punttu:~/incoming/ffmpeg$ ./ffmpeg -f dv1394 -i /dev/dv1394/0 -f 
> avi -acodec copy -vcodec copy -y outfile.avi
> FFmpeg version SVN-r9225, Copyright (c) 2000-2007 Fabrice Bellard, et al.
>    configuration: --enable-gpl --enable-pthreads --enable-x11grab 
> --enable-dc1394 --enable-liba52 --enable-liba52bin --enable-libfaac 
> --enable-libfaad --enable-libfaadbin --enable-libmp3lame --enable-libogg 
> --enable-libtheora --enable-libvorbis --enable-xvid
>    libavutil version: 49.4.0
>    libavcodec version: 51.40.4
>    libavformat version: 51.12.1
>    built on Jun  6 2007 00:52:53, gcc: 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
> Input #0, dv1394, from '/dev/dv1394/0':
>    Duration: N/A, start: 0.000000, bitrate: 30336 kb/s
>    Stream #0.0: Video: dvvideo, yuv420p, 720x576, 28800 kb/s, 25.00 fps(r)
>    Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, 1536 kb/s
> Output #0, avi, to 'outfile.avi':
>    Stream #0.0: Video: dvvideo, yuv420p, 720x576, q=2-31, 28800 kb/s, 25.00 
> fps(c)
>    Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, 1536 kb/s
> Stream mapping:
>    Stream #0.0 -> #0.0
>    Stream #0.1 -> #0.1
> Press [q] to stop encoding
> frame=    7 fps=  0 q=0.0 Lsize=    1939kB time=0.2 bitrate=66192.5kbits/s
> video:984kB audio:45kB global headers:0kB muxing overhead 88.389496%
> 

Yes, it was a bad suggestion, since it effectively forces the disk I/O 
to be interleaved with frame grabs, while we want them in parallel.

> 
> So back to the async (-o remount,async):
> 
> tuimonen at punttu:~/incoming/ffmpeg$ ./ffmpeg -f dv1394 -i /dev/dv1394/0 -f 
> avi -acodec copy -vcodec copy -y outfile.avi
> FFmpeg version SVN-r9225, Copyright (c) 2000-2007 Fabrice Bellard, et al.
>    configuration: --enable-gpl --enable-pthreads --enable-x11grab 
> --enable-dc1394 --enable-liba52 --enable-liba52bin --enable-libfaac 
> --enable-libfaad --enable-libfaadbin --enable-libmp3lame --enable-libogg 
> --enable-libtheora --enable-libvorbis --enable-xvid
>    libavutil version: 49.4.0
>    libavcodec version: 51.40.4
>    libavformat version: 51.12.1
>    built on Jun  6 2007 00:52:53, gcc: 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
> Input #0, dv1394, from '/dev/dv1394/0':
>    Duration: N/A, start: 0.000000, bitrate: 30336 kb/s
>    Stream #0.0: Video: dvvideo, yuv420p, 720x576, 28800 kb/s, 25.00 fps(r)
>    Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, 1536 kb/s
> Output #0, avi, to 'outfile.avi':
>    Stream #0.0: Video: dvvideo, yuv420p, 720x576, q=2-31, 28800 kb/s, 25.00 
> fps(c)
>    Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, 1536 kb/s
> Stream mapping:
>    Stream #0.0 -> #0.0
>    Stream #0.1 -> #0.1
> Press [q] to stop encoding
> frame=  706 fps= 23 q=0.0 Lsize=  231315kB time=28.2 
> bitrate=67196.2kbits/s
> video:99281kB audio:5288kB global headers:0kB muxing overhead 121.208528%
> 
> 
> I don't get the bitrate 67196.2kbits/s, since the input data is only 
> (28800+1536)*1000 bits/s. It's over twice the input rate.

The printed value for the bitrate is not very reliable. I think it's a 
bug, but that's a separate issue.

> 
> And the fps, being 24 just before I hit q and the encoding stopped, but 
> source is 25 fps.

The fps printed here is not the nominal but the effective fps.

> 
> Could it have something to do with 25fps not being defined (from 
> dc1394.c):
> 
> struct dc1394_frame_rate {
>      int frame_rate;
>      int frame_rate_id;
> } dc1394_frame_rates[] = {
>      {  1875, FRAMERATE_1_875 },
>      {  3750, FRAMERATE_3_75  },
>      {  7500, FRAMERATE_7_5   },
>      { 15000, FRAMERATE_15    },
>      { 30000, FRAMERATE_30    },
>      { 60000, FRAMERATE_60    },
>      {     0, FRAMERATE_30    } /* default -- gotta be the last one */
> };
> 
> and later in static int dc1394_read_header(AVFormatContext *c, 
> AVFormatParameters * ap)
> 
> 
>      for (fps = dc1394_frame_rates; fps->frame_rate; fps++)
>           if (fps->frame_rate == av_rescale(1000, ap->time_base.den, 
> ap->time_base.num))
>               break
> 
> 

I coulnt say, that's a question for the author.

> 
> 
>>> I have also tried to pipe dvgrab output to ffmpeg, but never figured out
>>> the right way to do it. I tried for instance
>>>
>>> dvgrab --format dv1 - | ffmpeg -i - -acodec copy -sameq -y outfile.avi
>>>
>>> but I got 'pipe:: could not find codec parameters' error.
>> Again, without the full output...
> 
> dvgrab pipe with dv2 output format:
> 
> tuimonen at punttu:~/incoming/ffmpeg$ dvgrab --format dv2 - | ./ffmpeg -i - 
> -acodec copy -sameq -y outfile.avi
> FFmpeg version SVN-r9225, Copyright (c) 2000-2007 Fabrice Bellard, et al.
>    configuration: --enable-gpl --enable-pthreads --enable-x11grab 
> --enable-dc1394 --enable-liba52 --enable-liba52bin --enable-libfaac 
> --enable-libfaad --enable-libfaadbin --enable-libmp3lame --enable-libogg 
> --enable-libtheora --enable-libvorbis --enable-xvid
>    libavutil version: 49.4.0
>    libavcodec version: 51.40.4
>    libavformat version: 51.12.1
>    built on Jun  6 2007 00:52:53, gcc: 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
> Capture Started
> pipe:: Unknown format

It means ffmpeg is unable to recognize a DV by probing. Add a -f dv (or 
something like that) before -i. I dont know DV at all, so you might have 
to add a -r and a -s too. Look in the archives

> 
> 
> with raw output format:
> 
> tuimonen at punttu:~/incoming/ffmpeg$ dvgrab --format raw - | ./ffmpeg -i - 
> -acodec copy -sameq -y outfile.avi
> FFmpeg version SVN-r9225, Copyright (c) 2000-2007 Fabrice Bellard, et al.
>    configuration: --enable-gpl --enable-pthreads --enable-x11grab 
> --enable-dc1394 --enable-liba52 --enable-liba52bin --enable-libfaac 
> --enable-libfaad --enable-libfaadbin --enable-libmp3lame --enable-libogg 
> --enable-libtheora --enable-libvorbis --enable-xvid
>    libavutil version: 49.4.0
>    libavcodec version: 51.40.4
>    libavformat version: 51.12.1
>    built on Jun  6 2007 00:52:53, gcc: 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
> Capture Started
> pipe:: could not find codec parameters

For a raw input, -f -r -s are certainly needed, probably -pix_fmt too.

> 
> 
> 
>> You are writing raw video to file. That eats a lot of I/O resources, and
>> a large fraction of that use will be concentrated in bursts - which will
>> interfere with the interrupts from the TV card.
> 
> Raw dv in PAL format and 48kHz stereo wav is roughly 4MB/s (estimated up). 
> Even old IDE harddisks can cope with this. My old AthlonXP was able to 
> grab 90min dv (using dvgrab) without one single frame lost.

Again, the 4MB is an average, but the caching in the OS can result in 
bursts.

> 
> AFAIK, Firewire was designed not to be 'bursty' (like USB is), but to 
> guarantee steady data stream. Of course I'm just waving hands and I 
> really don't know the internals of the implementation. And even if 
> firewire gives steady flow, the other resources might be on the bursty 
> side of the road.

If the OS and application dont take special pains to sustain the flow, 
it will be bursty anyway.

> 
>> There are various ways: patch ffmpeg so that there is an fsync after
>> every write; or a sync(2) after every frame write; or a separate process
>> that does a sync(2) every second; or write to a partition that is
>> mounted with -o sync.
> 
> The sync may not be the answer here, as it proved to be extremely slow.

Yes, my bad.

> And dvgrab performs fine on async filesystem, that rules out the I/O 
> resource issues.

No, you dont know what special care dvgrab might take to avoid I/O bursts.

> 
> I haven't yet browsed the code enough to see if the grabbing and writing 
> to disk are done in separate threads. At least in audio grabbing 
> (Ardour,ecasound and other decent hd recorders) it is a must that the disk 
> thread and audio thread are separated. Otherwise it will result to audio 
> dropouts.

If its important for a lean job like grabbing sound, it will be doubly 
so for a resource hog like video grabbing.

Oh, and IRQ clashes are important too. We had to fiddle with the 
placement of cards in PCI slots to avoid having other devices sharing 
IRQs with the video. What does your /proc/interrupts look like?

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


-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/




More information about the ffmpeg-devel mailing list