[FFmpeg-devel] [PATCH] avformat/mp3dec: set default disposition

[Gyan]

On 24-08-2019 04:43 PM, Hendrik Leppkes wrote:
> On Sat, Aug 24, 2019 at 11:28 AM Gyan <ffmpeg at 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