[FFmpeg-devel] [PATCH 2/6] lavu/channel_layout: implement unknown layouts.

[Carl Eugen Hoyos]

Nicolas George <nicolas.george <at> normalesup.org> writes:

> > (But I do of course not deny that the mono+mono 
> > case has to be dealt with. So far I assumed the 
> > optimal solution would be to export two mono 
> > audio streams.)
> 
> Demuxers can export several streams, decoder can 
> not. This mono+mono issue comes at the decoder level.

Yes, this is not so easy, thank you for explaining 
again.
I would like to add that imo, it would be acceptable 
if ffmpeg would only show the layout and the user 
would have to provide a filter chain himself.
(But this question should not really influence this 
discussion.)

[...]

> > I consider the current situation where the layout 
> > implicates the number of channels so inherently 
> > broken that I believe the argumentation that we 
> > have to keep backwards compatibility with this 
> > behaviour is completely adverse, especially since 
> > we are dealing with several regressions here.
> 
> Are you suggesting a lavfi major bump in a very near 
> future, then?

No, what I believe we should do is fix a regression 
that has already hit users several times and is blocking 
at least one more bug.
If the layout is set and matches the number of channels, 
it should be used, if it is set to "0", then no layout 
should be assumed (but processing should continue if 
at all possible, including for example reducing the 
number of channels).
(The error case of layout != 0 and number of channels 
inconsistent may cause an error, I don't know.)

> I do not oppose to that, note, but I was not aware 
> of any plans to that.

> Note that it is also an end to ffmpeg's 
> compatibility with libav.

I know of at least 500 more "features" of libav that 
ffmpeg does not support, this is a particularly bad 
one that we should not be compatible with because it 
is a regression.

Or in other words: Fixing buggy behaviour should not 
be seen as breaking api.
(Note that with your argumentation, we broke api quite 
often in the last months and I am in no way talking 
about obvious bugfixes, but changes in behaviour that 
everybody seemingly agreed with.)

Carl Eugen