[Ffmpeg-devel] channel ordering and downmixing

Justin Ruggles justinruggles
Fri Mar 30 03:39:23 CEST 2007

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.


More information about the ffmpeg-devel mailing list