[Ffmpeg-devel] channel ordering and downmixing

[Justin Ruggles]

Michael Niedermayer wrote:
> Hi
> 
> On Thu, Mar 29, 2007 at 07:54:10PM -0500, Justin Ruggles wrote:
> 
>>Paul Curtis wrote:
>>
>>>Justin Ruggles wrote:
>>>
>>>
>>>
>>>>#2) define a standard FFmpeg channel order and change decoders to always
>>>>   output in that order.  this would be simpler, but has the problem
>>>>   stated above with containers vs. codecs.  the demuxer could choose
>>>>   to tell the decoder the channel order or else leave it up to the
>>>>   decoder.  i can't think of a clean way to use this on the encoding
>>>>   side though.
>>>
>>>
>>>I, too, have been looking at this problem. Your second solution looks 
>>>like the best way to handle it. I had the idea of having a default 
>>>channel mapping to start with, then when the container was opened, if it 
>>>had a channel mapping, it would set it. If the codec had a different 
>>>mapping, it would then override the container's mapping. That way, a 
>>>container with PCM would set the mapping, or in the AC3 case, the codec 
>>>would override it. This is on decode.
>>
>>Yes, this was what I had in mind for decoding.
>>
>>
>>>On encode, that reverse process would occur ... the container would set 
>>>it's "preferred" channel mapping, and the codec could override it. You 
>>>could also have an option (a la 'mplayer') to force the mapping, if needed.
>>
>>That makes sense I guess.  One issue would be that the codec init
>>(avcodec_open) seems to be called before the muxer init
>>(av_write_header).  So the preferred channel order for the container
>>would need to be stored in the AVOutputFormat right?
> 
> 
> some random comments ...
> 
> dont forget that (de/en)codecs and (de)muxers can be connected in many ways
> that is demuxer->decoder->encoder->muxer, demuxer->muxer, 
> demuxer->decode->user, ...
> there can be delay between these steps (can ruin your day with channel
> order switching if for example the demuxer tries to change a channel
> order in AVCodecContext)

Yeah, that does make things messy.

>>In the meantime, another alternative to all of this might be to add a
>>separate API for audio channel layout which could do reordering and
>>downmixing.  It could be similar to the current resampling API.  That
> 
> 
> such a API will be needed anyway i think, or at least it would be usefull

Okay, I'm starting to lean toward this option.  One thing I just noticed
is that audio_resample does a deinterleave/resample/interleave process,
with some simple down/up-mixing in-between.  Would it be out of the
question to insert a channel ordering framework here?  Then the
ReSampleContext could be modified to include input layout and output
layout parameters...and substitute input_channels and output_channels in
audio_resample_init() with structs containing number of channels,
channel order, and possibly mixing coefficients.

-Justin