-vcodec huffyuv and a .mov container produces colorful static

[Steve]

You can use the clip attached to ticket #2190, i.e. https://ffmpeg.org/trac/ffmpeg/attachment/ticket/2190/ticket2190-clip.tar.bz2 -- though I think it'll probably happen with any input.

Here's the command I ran, with a version of git-master ffmpeg built just a few minutes ago.

% ffmpeg111 -i clip.yuv -vcodec huffyuv clip.mov
ffmpeg version 1.1.git Copyright (c) 2000-2013 the FFmpeg developers
  built on Jan 27 2013 10:12:30 with gcc 4.7.2 (GCC) 20120921 (Red Hat 4.7.2-2)
  configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg111 --incdir=/usr/include/ffmpeg111 --libdir=/usr/lib --mandir=/usr/share/man --arch=athlon --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=athlon -fasynchronous-unwind-tables' --enable-bzlib --disable-crystalhd --enable-gnutls --enable-libass --enable-libcdio --enable-libcelt --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopenjpeg --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib --progs-suffix=111 --build-suffix=111 --cpu=athlon --enable-runtime-cpudetect
  libavutil      52. 17.100 / 52. 17.100
  libavcodec     54. 91.100 / 54. 91.100
  libavformat    54. 61.104 / 54. 61.104
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter     3. 34.101 /  3. 34.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[yuv4mpegpipe @ 0x8d6f560] 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
File 'clip.mov' already exists. Overwrite ? [y/N] y
using huffyuv 2.2.0 or newer interlacing flag
[mov @ 0x8d77130] Using MS style video codec tag, the file may be unplayable!
Output #0, mov, to 'clip.mov':
  Metadata:
    encoder         : Lavf54.61.104
    Stream #0:0: Video: huffyuv, yuv422p, 720x480 [SAR 10:11 DAR 15:11], q=2-31, 200 kb/s, 30k tbn, 29.97 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> huffyuv)
Press [q] to stop, [?] for help
frame=    3 fps=0.0 q=0.0 Lsize=     953kB time=00:00:00.10 bitrate=78001.8kbits/s    
video:952kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.076493%

The result is brightly colored static.
There's warning in there -- "Using MS style video codec tag, the file may be unplayable!" -- but I get that with other clips I encode, and don't have any issues with them.

[Carl Eugen Hoyos]

The mov muxer should refuse to mux huffyuv and ffvhuff.

[Carl Eugen Hoyos]

Replying to cehoyos:

The mov muxer should refuse to mux huffyuv and ffvhuff.

Actually a regression since dcbf728, works fine with 1.0

[Carl Eugen Hoyos]

Also reproducible with the following command:
$ ffmpeg -i tests/lena.pnm -vcodec huffyuv out.mov

[TimNich]

Hmmm. The field order flagging is part of the mov spec that was previously ignored, and the huff codecs are not mentioned in the mov spec. Assuming we wish to continue to allow muxing huff in mov it looks like an exception needs to be added to the mov muxer for these codecs (already other codecs have differing moov atom requirements). Either that or refuse to mux as per the original comment. Which should it be?

[Steve]

Speaking as someone that doesn't know enough about video codecs etc. to develop ffmpeg...I would prefer that ffmpeg refuse to produce something that doesn't meet specs, and if asked to do so, ffmpeg should report an error and then provide some hints as to what would meet specs.

For example, after chatting with others on the #ffmpeg IRC channel, I eventually found three pixel formats that worked with raw video in a .mov container -- rgb24, uyvy422, and rgb565. But ffmpeg would generate files with other pixel formats, and then those files couldn't be decoded. This is unhelpful and unproductive. I would prefer that ffmpeg be stricter with the user's request, and in the above example, list what pixel formats would have been allowed with raw video in a .mov container.

[Carl Eugen Hoyos]

Replying to ulatekh:

I eventually found three pixel formats that worked with raw video in a .mov container -- rgb24, uyvy422, and rgb565. But ffmpeg would generate files with other pixel formats, and then those files couldn't be decoded. This is unhelpful and unproductive.

This is correct and definitely a bug.
But it is completely orthogonal to this regression.
(I would expect that yuyv422, several 32bit rgb formats, gray16be and rgb48be also work, if not this should be reported.)

[TimNich]

Replying to cehoyos:

Replying to ulatekh:

I eventually found three pixel formats that worked with raw video in a .mov container -- rgb24, uyvy422, and rgb565. But ffmpeg would generate files with other pixel formats, and then those files couldn't be decoded. This is unhelpful and unproductive.

This is correct and definitely a bug.
But it is completely orthogonal to this regression.
(I would expect that yuyv422, several 32bit rgb formats, gray16be and rgb48be also work, if not this should be reported.)

Agreed! My issue is that since, AFAIK, only ffmpeg supports huffman in a mov wrapper what should the behaviour be? I have looked at an example I created from a uyvy422 source and the moov atom structure looks correct, therefore do we regard the decoder as having an issue with mov's that contain a valid fiel atom, or do we regard adding this atom in a huffman codec context to be inappropriate? MY gut feeling is that the decoder shouldn't barf when presented with a valid set of atoms.

[Carl Eugen Hoyos]

Replying to nichot20:

Hmmm. The field order flagging is part of the mov spec that was previously ignored, and the huff codecs are not mentioned in the mov spec. Assuming we wish to continue to allow muxing huff in mov it looks like an exception needs to be added to the mov muxer for these codecs (already other codecs have differing moov atom requirements). Either that or refuse to mux as per the original comment. Which should it be?

Is there a problem with writing glbl atom after (or before) fiel atom?

[Carl Eugen Hoyos]

Replying to nichot20:

My issue is that since, AFAIK, only ffmpeg supports huffman in a mov wrapper

I don't think this is correct, a very quick search for example leads to this mail:
​http://permalink.gmane.org/gmane.comp.video.libquicktime.devel/958

(And MPlayer does support huffyuv and ffvhuff in mov.)

[TimNich]

Replying to cehoyos:

Replying to nichot20:

Hmmm. The field order flagging is part of the mov spec that was previously ignored, and the huff codecs are not mentioned in the mov spec. Assuming we wish to continue to allow muxing huff in mov it looks like an exception needs to be added to the mov muxer for these codecs (already other codecs have differing moov atom requirements). Either that or refuse to mux as per the original comment. Which should it be?

Is there a problem with writing glbl atom after (or before) fiel atom?

I don't know, I cannot find reference to the glbl atom in qtff, it appears to be an ffmpeg (and associates) private extension and I am not sure of the full history of it and why its currently not written. I'm currently trying to see why adding a standard atom is making the decoder barf when it was OK before.

[TimNich]

Replying to cehoyos:

Replying to nichot20:

My issue is that since, AFAIK, only ffmpeg supports huffman in a mov wrapper

I don't think this is correct, a very quick search for example leads to this mail:
​http://permalink.gmane.org/gmane.comp.video.libquicktime.devel/958

(And MPlayer does support huffyuv and ffvhuff in mov.)

Sorry I was meaning ffmpeg and other associated programs, i.e there is no "official" standard to comply with just a bunch of other programs with possible compatibility issues.

[Carl Eugen Hoyos]

Should be fixed in git head and future releases.

Thank you for the report!