[FFmpeg-devel] [PATCH 2/6] lavu/channel_layout: implement unknown layouts.
Carl Eugen Hoyos
cehoyos at ag.or.at
Thu Nov 29 21:02:51 CET 2012
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
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
> > 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.)
More information about the ffmpeg-devel