[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