[FFmpeg-devel] [PATCH 2/6] lavu/channel_layout: implement unknown layouts.
Carl Eugen Hoyos
cehoyos at ag.or.at
Thu Nov 29 17:48:17 CET 2012
Nicolas George <nicolas.george <at> normalesup.org> writes:
> I agree, but IMHO, the correct solution is pretty obvious,
> at least in its rough lines: deprecate
> "uint64_t channel_layout" in favour of "AVChannelSomething
> channel_something", with a data structure powerful enough
> to express "5.1+mono" or "mono[lang=ja]+mono[lang=en]".
> But until the deprecation is in full effect, i.e. until
> the next major bump, we have to make sense of that
> "uint64_t channel_layout".
I am not convinced that our goal should be to drop
"uint64_t channel_layout", I believe it works very
well for many cases and it represents very well the
usual usecase and the internal usage.
(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
Regarding your other mail:
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.
I therefore feel unable to comment much more,
More information about the ffmpeg-devel