This will allow us to encode 7.1 audio AAC.
7.1 audio not being really popular, instead of creating a new re_order
function, I'm using 2 functions for the re_ordering from
L R Ls Rs C LFE Rls Rrs --> C L R Ls Rs Rls Rrs LFE
Patch by Thierry Foucu [tfoucu gmail]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34877 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: ranma
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2012-April/070252.html
Only 1/3 of the samples in the buffer passed to reorder_channel_nch()
were being reordered. For 8-, 16-, and 32-bit audio, the buffers could
be treated as int8_t, int16_t, and int32_t respectively. 24-bit audio
was being processed as int8_t, requiring iteration over n_samples*3, not
n_samples.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29971 b3059339-0415-0410-9bf9-f77b7e298cf2
Where 8 channel support is non-trivial (e.g. ao_dsound), at least ensure we
fail gracefully.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29868 b3059339-0415-0410-9bf9-f77b7e298cf2
missed by r29427.
Patch submitted by Shane W, shane-mplayer csy ca
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29541 b3059339-0415-0410-9bf9-f77b7e298cf2
ffdca, ffflac, ffaac, fftruehd). In the process, adds support for 32-bit
samples.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29533 b3059339-0415-0410-9bf9-f77b7e298cf2
The reordering channels code had reoccurring bug
where in switch(samplesize) block the
case 3 (3 bytes) doesn't end with break;
leading to execution of the next case 4 too.
This mangles the already processed data and
causes massive memory corruption.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29427 b3059339-0415-0410-9bf9-f77b7e298cf2
This patch comes from Andrew de Quincey <adq_dvb at lidskialf dot net>.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27732 b3059339-0415-0410-9bf9-f77b7e298cf2
