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

[Chris Stones]

oops - correction / clarification.

ffmpeg -i VIDEO_1 -vcodec CODEC_1 TEST.nut -i VIDEO_2 -vcodec CODEC_2 -newvideo

the above can create a mapping of
0.0 -> 0.1
1.0 -> 0.0

so video_1 is the first stream in the output file, but it is encoded
with codec_2
video_2 is the second stream in the output file, but it is encoded with codec_1.



On 4/10/10, Chris Stones <chris.stones at gmail.com> wrote:
> 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.
>