[FFmpeg-soc] decoding 7_pt_1.eac3

[Michael Niedermayer]

On Sun, Apr 06, 2008 at 06:06:45PM +0200, Bartlomiej Wolowiec wrote:
> On niedziela, 6 kwietnia 2008, Michael Niedermayer wrote:
> > On Sat, Apr 05, 2008 at 11:18:55PM +0200, Bartlomiej Wolowiec wrote:
> > > Hi,
> > > while decoding information from 7_pt_1.eac3 I got unsatisfactory
> > > results... I mean that I don't know how is channel_map related to
> > > channels in the frame:
> > >
> > > [ac3 @ 0x8444bb0]channel_mode=7 lfe=1 (channels = 6)
> > > [ac3 @ 0x8444bb0]channel_mode=5 lfe=0 (channels = 4)
> > >
> > > [ac3 @ 0x8444bb0]channel_map = 00001101000000000
> >
> > channel_map has 16 bits, what you print here has 17 digits
> >
> > > (set bits: 9 - Lsd/Rsd pair, 11 - Lvh/Rvh pair, 12 - Cvh)
> >
> > to me this looks like bits 3,4 and 6
> >
> > [...]
> 
> When it reads while using get_bits it gets 0x1a00 value...
> Description of bites is strange, because in remaining part of documentation 
> there is "normal" order.
> So, what is better?
> -to read and reverse order of bits. I haven't seen such possibility, so should 
> something like this be done:
>         ret = (ret & 0x00FF) << 8 | (ret & 0xFF00) >> 8;
>         ret = (ret & 0x0F0F) << 4 | (ret & 0xF0F0) >> 4;
>         ret = (ret & 0x3333) << 2 | (ret & 0xCCCC) >> 2;
>         ret = (ret & 0x5555) << 1 | (ret & 0xAAAA) >> 1;
> -write the whole code differently than in eac3 documentation (reverse bits)

if all files store the bits reversed then yes the code should be written to
match that.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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-soc/attachments/20080406/32b6546b/attachment.pgp>