[Ffmpeg-devel] channel ordering and downmixing
Fri Mar 30 03:39:23 CEST 2007
Michael Niedermayer wrote:
> 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