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

Michael Niedermayer michaelni at gmx.at
Thu Nov 29 17:32:42 CET 2012

On Thu, Nov 29, 2012 at 01:35:57PM +0100, Nicolas George wrote:
> Le nonidi 9 frimaire, an CCXXI, Michael Niedermayer a écrit :
> > IMHO we should decide what is the correct solution and work toward
> > that.
> 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]".

The problem is the code uses the current layout for finding the number
of channels, adding a new system and deprecating the old does not
fix it.

not using the layout for finding the array size fixes it

these are 2 seperate things.
If you add a "better" system then in 90% of the cases that cant be
handled currently i suspect it will just list "unknown layout" of
X channels.
We can do that today, its layout = 0

> 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".

> > IMHO the correct solution is to never trust the layout to tell the
> > array size. And to just set it to 0 when its unknown.
> Yes, but lavfi does not allow us to do that.

lavfi is a bunch of bits / bytes / source code, it sure can be changed
by us.

> > I dont think this breaks ABI/API, an application that works within
> > the API that |layout| == channel count will never insert things into
> > the filter graph that dont conform to that and the filter framework
> > from itself wont produce a mismatch
> Once again, you forget lavfi. Consider the following application:
> 	open_filter(&sink, "movie=file.mp3:s=a, "
> 	            "aformat=sample_fmts=s16:sample_rates=48000");

movie fails in this case due to a unsupported channel layout, it has
to currently for sure and i dont see why this should change if we
allow layout=0 on filter graph input


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121129/3af367d9/attachment.asc>

More information about the ffmpeg-devel mailing list