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

[Nicolas George]

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.

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

Regards,

-- 
  Nicolas George
-------------- 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/04edd318/attachment.asc>