ffmpeg 2.0.2 - ffv1 codec is bogus

[andre.dos.anjos@…]

Apparently, ffmpeg (at least version 2.0.2) has a mal-functioning "ffv1" codec. The attached program replicates the problem. It was extracted from the example section of the ffmpeg manual (​http://ffmpeg.org/doxygen/2.0/doc_2examples_2muxing_8c-example.html), slightly modified to force the FFV1 codec by replacing lines 419-421 (with video_st = add_stream(oc, &video_codec, AV_CODEC_ID_FFV1)). It used to at least, before the updated to 2.0.

Compiling and linking:

clang -I/opt/local/include test.c -L/opt/local/lib -lavutil -lavcodec -lavformat -lswscale -lswresample -o ffmpeg_test

Running:

./ffmpeg_test test.avi

[mf2k (Frank Schima)]

In the future, please use WikiFormatting and Cc the port maintainers (port info --maintainers ffmpeg).

[andre.dos.anjos@…]

Some more information:

1. The test works with ffmpeg@1.2.2_0
2. The test does not work with ffmpeg@2.0.1_1

At this point, my only conclusion is that something happened after the upgrade that made this codec bogus. I attach the example that works for ffmpeg-1.x. (test-1x.c). Just compile it the same way as before.

[dbevans (David B. Evans)]

My results seem to be consistent with yours.

Both programs build without error with their respective ffmpeg version (I'm using ffmpeg@2.0.2 and ffmpeg@1.2.2).

Running the ffmpeg@2.0.2 version fails with errors and produces a corrupted avi file with video and audio streams.

$ ./ffmpeg_test test.avi
[libmp3lame @ 0x7fa7d201f200] Channel layout not specified
Output #0, avi, to 'test.avi':
    Stream #0:0: Video: ffv1, yuv420p, 352x288, q=2-31, 400 kb/s, 90k tbn, 25 tbc
    Stream #0:1: Audio: mp3 (libmp3lame), 44100 Hz, 2 channels, fltp, 64 kb/s
Error encoding video frame: Invalid argument

The ffmpeg@1.2.2 version run successfully and produces a valid avi file (video only, no audio stream)

$ ./ffmpeg_test-1x test-1x.avi
Output #0, avi, to 'test-1x.avi':
    Stream #0:0: Video: ffv1, yuv420p, 352x288, q=2-31, 400 kb/s, 90k tbn, 25 tbc

Comparing the two programs with diff shows what I would call substantial differences in code. Obviously there are substantial (upstream) changes in the ffmpeg code as well between these two versions.

MacPorts just packages the code supplied from upstream. So I would think that this is a problem that you should take up with the ffmpeg developers. I would suggest the ffmpeg-users list to start.

I don't see any indication that the problem stems from MacPorts itself unless you have other evidence to that effect.

[andre.dos.anjos@…]

Thanks, this is now cross-posted on the libav-users mailing list (seems to be the more adequate one for these matters):

​http://ffmpeg.org/pipermail/libav-user/2013-October/005734.html

[dbevans (David B. Evans)]

Reply on libav-users indicates that this problem stems from problems with the version 2.* example code used in this test. Since 2.0, initialization requirements for the ffv1 encoder have changed.

Closed as invalid meaning not a MacPorts issue (upstream online example code needs review).

See ​http://ffmpeg.org/pipermail/libav-user/2013-October/005737.html