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

Michael Niedermayer michaelni at gmx.at
Sun Dec 2 17:01:17 CET 2012


On Sun, Dec 02, 2012 at 01:47:19PM +0100, Nicolas George wrote:
> Le nonidi 9 frimaire, an CCXXI, Michael Niedermayer a écrit :
> > What i meant was:
> > Axiom 1. the movie source does not set |layout| != number channels
> > Axiom 2. source filters that take input from the application accept
> >          and pass on the layout if it is 0
> > Axiom 3. All other filters not mentioned in previous axioms never
> >          output layout 0 unless one of its inputs is layout 0
> > 
> > The intent here is layout either
> > A. "matches" the channel count or
> > B. is explicitly set to 0 by the application
> > there is by design no way to ever get a layout = 0 without the
> > application having set it to that.
> > 
> > A. is what the API requires
> > B. implicates that the application supports layout 0 because the
> >    application itself inputs data that is outside the API
> > 
> > 
> > This would solve passing unknown or odd layouts through libavfilter
> > and even do some simple filtering with it like samplerate or volume
> > changing.
> > 
> > and above all, this looks quite simple to do
> 
> I see. I believe it can work, but it does not seem very robust: a bug in any
> filter can easily break the axioms; but my proposal was not very robust
> either.
> 
> Also, there are cases where it would make sense for a filter to output
> layout=0 even if its input are known: amerge(stereo, stereo), for example,
> should output layout=0; instead, it currently outputs quad and prints a
> warning.
> 
> And there is a bigger problem: the channel layout is currently used for the
> format negotiation. Implementing this solution would require reworking
> completely that part. Fortunately, the in/out_channel_layouts fields are
> private, we can extend their semantic without risk.
> 
> (A small but fortunate coincidence: bit 63 of channel layouts is reserved
> for something entirely different; therefore, we can use it to code extra
> information without changing the data structure. In the rest of the message,
> consider that U(n) means n|(1<<63).)
> 
> I can suggest:
> 
> A: in/out_channel_layouts = { } means "any known channel layout" (just like
>    right now, in fact).
> 
> B: in/out_channel_layouts = { 0 } means "any channel layout, known or
>    unknown";
>

> C: in/out_channel_layouts = { ..., U(n), ... } means that any channel
>    layout, known or unknown, with n channels, is accepted.


> 
> Note that it requires rewriting the intersection function completely,
> because, for example, U(2) and STEREO can be matched. But that can certainly
> be done.
> 
> Also, the axioms you stated before become unnecessary: to protect an
> application from getting unexpected layout=0 output, it is enough to set
> buffersink list of supported layouts to { } instead of { 0 } by default. We
> just have to resurrect AVABufferSinkParams to do that.
> 
> I believe it can work quite well. Therefore, the current patch is dropped.
> 
> OTOH, I would like to be sure we agree on the side points:
> 

> - The TrueHD decoder outputting 2 channels with layout=MONO is actually a
>   bug, due to the layout not being updated when the number of channels
>   changes.

I did not investigate this much but it sound likely that its a bug


> 
> - Having layout != 0 but still |layout| != nb_channels is not a good idea,
>   as it goes against the principle of least surprise. (Being able to flag
>   dual-mono as MONO is not worth it, especially since 2 channels +
>   layout=unknown can hardly be anything else.)

it can be stereo as well.
unknown just says unknown not that its not a known standard format

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20121202/f398ae29/attachment.asc>


More information about the ffmpeg-devel mailing list