[FFmpeg-devel] [PATCH] lavd/oss: support for more than 2 channels

Nicolas George nicolas.george at normalesup.org
Fri Jul 20 18:40:31 CEST 2012

Le tridi 3 thermidor, an CCXX, Paul B Mahol a écrit :
> Really? Channel ordering have nothing to do with this patch, without this

Any patch that deals with more than 2 channels has to do with channel
layouts and ordering. Or you end up with files that have the back left
channel where the front center should be.

> patch more than 2 channels data is not played correctly at all.
> (So better something than nothing).

Actually, it is quite reasonable to consider it worse to produce invalid
results than to produce no results at all. Especially if the invalidity is
subtle and can easily go unnoticed.

At the very least, a warning advising that the layout is wrong would be

I can provide an Ogg Vorbis file that makes a good test case if you want to
implement things properly.

>				      This is what mplayer(2) use.

MPlayer's internal channel ordering is FL-FR-BL-BR-FC-LF, which happens to
be the same as ALSA, and certainly OSS too (in fact, I believe it is the
order of the standard hardwares).

FFmpeg's internal channel ordering, when the layout is 5.1, is

That means MPlayer does not need to reorder in audio output drivers, but it
needs to reorder in FFmpeg glue code (see the call to reorder_channel_nch()
in libmpcodecs/ad_ffmpeg.c).

FFmpeg, on the other hand, does not need to reorder when dealing with a lot
of common formats, but it needs to in some devices or external libraries.
See all the REORDER macros in libavdevice/alsa-audio-common.c, or the use of
ff_vorbis_encoding_channel_layout_offsets in libavcodec/libvorbisenc.c.

> Why reordering? Isn't reordering meant to be done with libswr?
> Isn't that libavdevice audio outdevs should play only channel order they
> actually support, and any reordering should be done in libswr and not in
> lavd itself.

libswr implements an API to do the reordering (but is only efficient with
planar formats), but it is not automatically used. The policy that was
decided a long time ago is that everything inside FFmpeg uses the WAVE
channel order, and interfaces to external stuff should take care of
reordering if necessary.

> > What happens if you call "SNDCTL_DSP_CHANNELS, 2" instead of
> I do not care.

That would make the whole code simpler, and it would have taken you half a
minute to test.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120720/d67cbeaa/attachment.asc>

More information about the ffmpeg-devel mailing list