[FFmpeg-user] ffv1 version 3 read_quant_table error

[Dave Rice]

On Feb 12, 2013, at 7:26 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Dave Rice <dave <at> dericed.com> writes:
> 
>>> This is a duplicate of ticket #2202, I sent a patch 
>>> to the mailing list, it is still waiting for somebody 
>>> who can test with AVID dnxhd decoder installed.
>> 
>> I have ffmpeg compiled with your patch and the AVID 
>> dnxhd quicktime component installed. What is the test?
> 
> Encode the sample from ticket #2190 to dnxhd both with 
> and without my patch

With patch:
./ffmpeg -i clip.yuv -c:v dnxhd -s 1920x1080 -b:v 175M with_patch.mov
ffmpeg version N-49846-ge1219cd Copyright (c) 2000-2013 the FFmpeg developers
  built on Feb 12 2013 19:06:28 with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
  configuration: 
  libavutil      52. 17.101 / 52. 17.101
  libavcodec     54. 91.103 / 54. 91.103
  libavformat    54. 63.100 / 54. 63.100
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 37.101 /  3. 37.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
[yuv4mpegpipe @ 0x7f88e400f200] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from 'clip.yuv':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: rawvideo (Y41B / 0x42313459), yuv411p, 720x480, SAR 10:11 DAR 15:11, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Output #0, mov, to 'with_patch.mov':
  Metadata:
    encoder         : Lavf54.63.100
    Stream #0:0: Video: dnxhd (AVdn / 0x6E645641), yuv422p, 1920x1080 [SAR 135:176 DAR 15:11], q=2-1024, 175000 kb/s, 30k tbn, 29.97 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> dnxhd)
Press [q] to stop, [?] for help
frame=    3 fps=0.0 q=1.0 Lsize=    2689kB time=00:00:00.10 bitrate=220060.1kbits/s    
video:2688kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.035967%

Without patch:
ffmpeg -i clip.yuv -c:v dnxhd -s 1920x1080 -b:v 175M without_patch.mov
ffmpeg version 1.1.git Copyright (c) 2000-2013 the FFmpeg developers
  built on Feb 12 2013 19:07:29 with Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --cc=cc --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-ffplay --enable-libopenjpeg --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1/include/openjpeg-1.5 '
  libavutil      52. 17.101 / 52. 17.101
  libavcodec     54. 91.103 / 54. 91.103
  libavformat    54. 63.100 / 54. 63.100
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 37.101 /  3. 37.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[yuv4mpegpipe @ 0x7fc768836e00] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from 'clip.yuv':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: rawvideo (Y41B / 0x42313459), yuv411p, 720x480, SAR 10:11 DAR 15:11, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Output #0, mov, to 'without_patch.mov':
  Metadata:
    encoder         : Lavf54.63.100
    Stream #0:0: Video: dnxhd (AVdn / 0x6E645641), yuv422p, 1920x1080 [SAR 135:176 DAR 15:11], q=2-1024, 175000 kb/s, 30k tbn, 29.97 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> dnxhd)
Press [q] to stop, [?] for help
frame=    3 fps=0.0 q=1.0 Lsize=    2689kB time=00:00:00.10 bitrate=220059.3kbits/s    
video:2688kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.035604%

> (and verify that the files are 
> different: one should contain a fiel atom, one not).

This is true. I can find the fiel atom in with_patch.mov but not in without_patch.mov, but I am only discovering this with a hexdump of each file. Dumpster doesn't reveal the fiel atom, nor does mediainfo --inform='Details;1'. Is there another atom parser to use?

> The question is if both can be decoded with QuickTime.

Both appear to operate appropriately and identically within QuickTime 7.6 and QuickTime X.

> Thank you!

Thanks too,
Dave