On 10/22/13, Andre Anjos <[email protected]> wrote: > Hello, > > I'm using a MacPorts build of ffmpeg 2.0.2. It passes most of our tests, > except the one using the FFV1 codec. This seems independent of the file > format chosen. > > How to reproduce the problem: > > 1) Download the muxing example from the ffmpeg doxygen documentation ( > http://ffmpeg.org/doxygen/2.0/doc_2examples_2muxing_8c-example.html) > > 2) By the end of the application, replace the code: > > if (fmt->video_codec != AV_CODEC_ID_NONE) { > video_st = add_stream(oc, &video_codec, fmt->video_codec); > } > > With: > > video_st = add_stream(oc, &video_codec, AV_CODEC_ID_FFV1) > > So, that the FFV1 codec is forced. > > 3) Compile the program (on OSX, that would be): > > clang -I/opt/local/include test.c -L/opt/local/lib -lavutil > -lavcodec -lavformat -lswscale -lswresample -o ffmpeg_test > > 4) Run the program: > > ./ffmpeg_test foo.avi > > to get: > > [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 > > Result: Bogus file, with error > > Expected result: clean file with no errors. > > Can anyone confirm this or provide some light on what I could possibly be > doing wrong? A developer from MacPorts has confirmed the problem - it does > not happen on 1.2.x. It does happen with 2.0.1 and 2.0.2 ( > https://trac.macports.org/ticket/40829). > > Thanks in advance, A
FFmpeg 2.0.X does not have bogus FFV1 codec. The examples code is of very low quality. FFV1 encoder have been changed in its initialization to abort when width/height is not set. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
