On 24-08-2019 04:43 PM, Hendrik Leppkes wrote:
On Sat, Aug 24, 2019 at 11:28 AM Gyan <ffm...@gyani.pro> wrote:
Fixes #8091, which reports what I consider a change rather than a
regression since 11d3b03fcb2baae4324aac9481b9bd4a171d4345
<http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=11d3b03fcb2baae4324aac9481b9bd4a171d4345>
It may be good practice to set default disposition in all demuxers which
only accept one stream of a type.
Any disposition should only be set if the container has any metadata
to indicate them, not blindly be set for no particular reason.
For the ticket in question, if you want to replace a stream in a file,
you should manually ensure its mapped properly.
The ticket reports a change in auto-mapping behaviour. Manual mapping is
a workaround which I already provided at trac but it doesn't correct the
regression which should be addressed since I've confirmed that
auto-mapping is affected for instances beyond that in the ticket e.g.
ffmpeg -i avi -i mp4 outfile where both files have streams with
identical parameters.
Maybe a better change is to revert or refine 11d3b03fcb2 since
disposition was originally introduced to convey and store flags in two
particular formats: nut and matroska but the ffmpeg tool now
unconditionally gives *default disposition* weight in selecting streams.
Note: the MOV demuxer abuses the field by setting default disposition
based on whether a stream is enabled so you can have a MP4 with N
streams of a type, all being marked as default.
For containers which only support one stream of a type (A, V or S) or
raw bitstreams, metadata can't be expected since there's no choice or
preference to be signaled; it is implicit that the one and only possible
track is the 'default' one, so it is not a blind or wayward assignment.
But this patch was a narrow fix for 8091 so I don't care to press for it.
Gyan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
