[MPlayer-dev-eng] [PATCH] Support 32-bit samples in ad_ffmpeg (fixes improper channel ordering in flac)
Jason Tackaberry
tack at urandom.ca
Fri Aug 7 20:52:47 CEST 2009
Hi all,
Uoti's response to my hasty "-channels 8" patch prompted me to
investigate and become familiar with channel ordering in MPlayer. In
the process, I have uncovered some bugs.
The first is that, with ad_ffmpeg at least, channel reordering is broken
with 32-bit samples. ad_ffmpeg calls reorder_channel_nch() to shuffle
channels (whose source order varies by codec) into MPlayer's standard
order; it however assumes 16-bit samples always, so reordering fails
when 32-bit samples are used.
Based on the past builds I have lying around on my system, it looks like
where in late February or early March 2009, ffmpeg's flac decoder added
support for s32le samples. I've generated a 5.1 channel flac file
(transcoded from DTS-HD MA from one of my Blurays) that, with a recent
build of mplayer, has incorrect channel ordering because of the
hardcoded 16-bit assumption.
So the attach patch fixes this particular issue, and after testing
various types of content (16-bit: ac3, dts, flac; 32-bit: truehd, flac)
via ad_ffmpeg, it works correctly (although you may want to tweak the
formatting).
This patch will also be needed for fixing channel ordering of TrueHD,
which is decoded into 32-bit samples. More changes will be needed for
that, and I'll submit a patch for that once I do further testing.
The second issue I ran into (which is not addressed by this patch, but
it merits discussion) is that the channel ordering for at least 5.1 AC3
and DTS is completely messed up when using ad_ffmpeg. MPlayer's default
decoders (dts and a52) are correct, so this probably isn't affecting
many users. However, ffac3 and ffdca are broken. (I'll also mention
that downmixing DTS from 6 to 2 channels with ffdca [and even ffmpeg
directly] is also incorrect. I'll pursue that on ffmpeg-devel at some
point.)
I have an old build from 2008-09-20 that is fine, but my next build
(from 2009-02-02) is busted, so I'm guessing that somewhere between
those dates, channel ordering was changed in ffmpeg's audio decoders. I
could do more leg work, but I'm hoping those of you more familiar with
ffmpeg's commit history will know when and what happened.
After some fairly cursory testing, it does appear that the ffmpeg audio
decoders might have standardized on SMPTE/ITU channel ordering, because
setting AF_CHANNEL_LAYOUT_LAVC_DCA_6CH_DEFAULT and
AF_CHANNEL_LAYOUT_LAVC_AC3_6CH_DEFAULT in libaf/reorder_ch.h both to
AF_CHANNEL_LAYOUT_5_1_A fixes the channel ordering. I've not yet had a
chance to test other content.
Those tracking ffmpeg commits, does this sound familiar?
As an aside, is AF_CHANNEL_LAYOUT_LAVC_LIBA52_DEFAULT relevant or used
for anything? It's referenced in ad_ffmpeg.c for the "liba52" codec,
but I can't find a codec so named in ffmpeg.
Cheers,
Jason.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ad_ffmpeg-32bit-samples.patch
Type: text/x-patch
Size: 1040 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090807/fc168596/attachment.bin>
More information about the MPlayer-dev-eng
mailing list