[Ffmpeg-devel] channel ordering and downmixing

Michael Niedermayer michaelni
Fri Mar 30 02:19:24 CEST 2007


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)


[...]
> 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

PS: no i dont have any real ideas on how to implement the channel order
stuff cleanly ATM :(

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070330/85afb188/attachment.pgp>



More information about the ffmpeg-devel mailing list