[FFmpeg-devel] [RFC] Channel layouts

Peter Ross pross
Mon Sep 8 02:26:12 CEST 2008


On Sun, Sep 07, 2008 at 11:25:01AM -0400, Justin Ruggles wrote:
> Hi,
> 
> Andreas ?man wrote:
> > M?ns Rullg?rd wrote:
> >> Don't forget that the channel layout must specify not only which
> >> components are present, but also their order.  Currently lavc tells
> >> you neither, making it practically useless for multi-channel audio.
> > 
> > The idea is that the order is the same as the CHANNEL_LAYOUT bits.
> > I.e. LEFT must be the first channel if it exists, then RIGHT, etc.
> > Still, this would only be mandatory for codecs (and formats) that
> > specifies channel_layout.
> 
> There should still be a way for the demuxer to communicate the source
> channel order.  Sure, most codecs have a defined channel order, but raw
> PCM does not.  The demuxer should not reorder the channels, but the
> user-level does need to know what that order is.

Agree.

One way to accomodate this would be to provide a channel reordering matrix,
that is set by the demuxer. The PCM codecs, and potentially others, would
use this to apply the correct order. The matrix could also be used by user
applications to handle layout-variation between FFmpeg and the output
device (OSS/ALSA/SDL/Win32).

> > This is IMHO no more strange than that PIX_FMT_YUV always have
> > the planes in Y,U,V order. From an application perspective i find
> > this much more convenient. There might be more work in the decoders
> > though. Still, with float_to_int16_interleave() (that all of the
> > "popular" multi-channel codecs currently use (AC3, DTS and AAC))
> > this is just a matter of swizzling a few pointers at setup time.
> 
> I don't know if there is the same complexity of ordering in video as in
> audio.  I do see that we have different PIX_FMT's for RGB and BGR.

IMHO it is the same concept, but implemented with less permutations.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080908/b92b7b5d/attachment.pgp>



More information about the ffmpeg-devel mailing list