[FFmpeg-devel] Michael's ffmpeg.c patch - Favor streams with more packets if the user did not specify what she wants.

[Chris Stones]

This patch http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=920cfe58c3137df7df8070bf3c3e16de7bca7394;hp=c1c88455372de3ce06e462b26c21f375cfa1512b

fixes an old issue ( https://roundup.ffmpeg.org/issue1156 )

But changes the behavior of the command line options, breaks my
software ( and therefore probably other FFmpeg reliant software ). And
in my opinion, makes the command line options more difficult to
understand and error-prone.

Take a look at the following command line, it encodes one video as
Mpeg4, and one as SNOW.
each with different qscales.

~/workspace/ffmpeg/ffmpeg -i /tmp/2snut_wJ6sAf/rgb%06d.png -strict -2
-vcodec snow -pix_fmt yuv420p -qscale 2.0 -f nut -y ~/test1.nut -i
/tmp/2snut_wJ6sAf/a%06d.png -strict -2 -vcodec mpeg4 -pix_fmt yuv420p
-qscale 6.0 -newvideo


Before the above patch, it was easy to see that rgb%06d.png would be
encoded with the SNOW codec, at quantize scale 2, and video a%06d.png
would be encoded as an mpeg4, with a 6.0 quantize scale.

However, after the patch, because order is determined by number of
packets,  it is impossible for the user to know what is going to be
encoded with what settings / which codec.

In the case of my sample media ( both videos are identical in frame
number and resolution, but a%06d.png is much smaller. ) the a%06d.png
video is encoded with snow, qscale 2. and a%06d.png is an mpeg4 at
qscale 6.

in other words, every script, everywhere is going to need to add "-map
0.0 -map 1.0 ....  -map n.0"
to the end of every "-newvideo" option.

If this patch is not going to be un-done, then I think the
documentation needs updating, as the implicit order of "-newvideo"
nolonger is nolonger sane ?

But thats just my opinion..
Any thoughts ????

THANKS
Chris.