[FFmpeg-user] Avid DNxHD QTs dropped/doubled frame problem

[Jesse Lucas]

On 24/08/11 13:35 -0700, Michael Root wrote:
>> On 08/24/2011 12:44 PM, Jesse wrote:
>> Hi, all.  I've run in to an issue when importing DNxHD Quicktime
>> movies made with ffmpeg in to Avid Media Composer.
>> The source material are image sequences rendered at 24 FPS.
>>
>> The output format is DNxHD 36 Mb/s, 23.976 FPS.
>>
>> I am doing my encoding with ffmpeg SVN-r20372 packaged with Fedora
>> Core 12.
>>
>> All output movies from ffmpeg play back with the correct number of
>> frames in mplayer on Linux, and in Quicktime on a Mac.
>>
>> However, when the movies are imported in to an Avid Media Composer
>> project set to DNxHD36, 23.976 FPS, movies with frame lengths ending
>> in 0, 3, and 6 (e.g.  10, 13, 16, 20, 23, ...), have a doubled first
>> frame, and a missing last frame.
>>
>> All DNxHD36 Quicktimes created with Quicktime on a Mac maintain the
>> correct order and number of frames when imported in to the Avid, which
>> is why I think my problem originates with ffmpeg.
>>
>>
>> This is an example of my ffmpeg command on Linux:
>>
>> ffmpeg -f image2 -r 24 -i ./1-20/test.%04d.tif -vcodec dnxhd -b 36Mb -r 23.976 -s 1920x1080 ./test.1-20.mov
>>
>>
>> This is the complete terminal output of the run.
>>
>> FFmpeg version SVN-r20372, Copyright (c) 2000-2009 Fabrice Bellard, et al.
>>    built on Nov  7 2009 10:57:27 with gcc 4.4.2 20091027 (Red Hat 4.4.2-7)
>>    configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --extra-version=rpmfusion --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libfaad --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avfilter-lavf --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
>>    libavutil     50. 3. 0 / 50. 3. 0
>>    libavcodec    52.37. 1 / 52.37. 1
>>    libavformat   52.39. 2 / 52.39. 2
>>    libavdevice   52. 2. 0 / 52. 2. 0
>>    libavfilter    1. 4. 1 /  1. 4. 1
>>    libswscale     0. 7. 1 /  0. 7. 1
>>    libpostproc   51. 2. 0 / 51. 2. 0
>> [image2 @ 0x9735e0]MAX_READ_SIZE:5000000 reached
>> Input #0, image2, from '1-20/test.%04d.tif':
>>    Duration: 00:00:00.83, start: 0.000000, bitrate: N/A
>>      Stream #0.0: Video: tiff, rgb24, 1920x1080, 24 tbr, 24 tbn, 24 tbc
>> Output #0, mov, to './test.1-20.mov':
>>      Stream #0.0: Video: dnxhd, yuv422p, 1920x1080, q=2-31, 36000 kb/s, 2997 tbn, 23.98 tbc
>> Stream mapping:
>>    Stream #0.0 ->  #0.0
>> Press [q] to stop encoding
>> frame=   20 fps=  8 q=1.0 Lsize=    3681kB time=0.83 bitrate=36148.6kbits/s
>> video:3680kB audio:0kB global headers:0kB muxing overhead 0.024573%
>>
>>
>> Does anyone see anything conspicuously wrong with my command line that
>> would cause the behavior I described above?   Is it normal to see
>> "2997 tbn, 23.98 tbc" when writing DNxHD Quicktimes?
>>
>> Thanks for reading.
>>
>> -Jesse
>
> We had the same problem.  This fixed it:
>
> --- libavformat/movenc.c        2011-08-24 13:33:37.000000000 -0700
> +++ libavformat/movenc.c.orig   2011-08-24 13:33:23.000000000 -0700
> @@ -1392,10 +1392,8 @@
>      avio_wb32(pb, 0); /* size */
>      ffio_wfourcc(pb, "trak");
>      mov_write_tkhd_tag(pb, track, st);
> -    if (track->mode == MODE_PSP
> -        || track->flags & MOV_TRACK_CTTS
> -        || track->enc->codec_id == CODEC_ID_DNXHD)
> -        mov_write_edts_tag(pb, track);  // DNXHD and PSP Movies require edts box
> +    if (track->mode == MODE_PSP || track->flags & MOV_TRACK_CTTS ||  
> track->cluster[0].dts)
> +        mov_write_edts_tag(pb, track);  // PSP Movies require edts box
>      if (track->tref_tag)
>          mov_write_tref_tag(pb, track);
>      mov_write_mdia_tag(pb, track);
>
>
> There are still (relatively minor) colorspace problems, though.  
> JFYI.

Thanks a lot, Mike.

I applied that patch to ffmpeg from git as of an hour ago, compiled, 
and it did indeed produce a DNxHD36 Quicktime that imported in to our 
Avid without the problems I was seeing before.

So, is this an ffmpeg bug, or an Avid bug?

If the former, was this patch submitted to the ffmpeg-devel list?  Any 
idea why it hasn't yet been merged in, or an equivalent fix made since  
the problem has been identified?

Here is the patch again against current ffmpeg source.


--- libavformat/movenc.c.orig   2011-08-25 15:19:22.000000000 -0400
+++ libavformat/movenc.c        2011-08-25 15:24:42.000000000 -0400
@@ -1392,7 +1392,10 @@
     avio_wb32(pb, 0); /* size */
     ffio_wfourcc(pb, "trak");
     mov_write_tkhd_tag(pb, track, st);
-    if (track->mode == MODE_PSP || track->flags & MOV_TRACK_CTTS || track->cluster[0].dts)
+    if (track->mode == MODE_PSP ||
+        track->flags & MOV_TRACK_CTTS ||
+        track->cluster[0].dts ||
+        track->enc->codec_id == CODEC_ID_DNXHD)
         mov_write_edts_tag(pb, track);  // PSP Movies require edts box
     if (track->tref_tag)
         mov_write_tref_tag(pb, track);


Thanks again.

-J