[MPlayer-cvslog] r24453 - trunk/libmpcodecs/ad_hwac3.c

[Ulion]

2007/9/14, reimar <subversion at mplayerhq.hu>:
> Author: reimar
> Date: Fri Sep 14 10:56:04 2007
> New Revision: 24453
>
> Log:
> Improved comments, based on patches by Ulion [ulion2002 gmail com]
>
>
> Modified:
>    trunk/libmpcodecs/ad_hwac3.c
>
> Modified: trunk/libmpcodecs/ad_hwac3.c
> ==============================================================================
> --- trunk/libmpcodecs/ad_hwac3.c        (original)
> +++ trunk/libmpcodecs/ad_hwac3.c        Fri Sep 14 10:56:04 2007
> @@ -160,12 +160,12 @@ static int decode_audio(sh_audio_t *sh_a
>    else if(isdts == 0)
>    {
>      uint16_t *buf16 = (uint16_t *)buf;
> -    buf16[0] = 0xF872;
> -    buf16[1] = 0x4E1F;
> -    buf16[2] = 0x0001;
> -    buf16[3] = len << 3;
> +    buf16[0] = 0xF872;   // iec 61937 syncword 1
> +    buf16[1] = 0x4E1F;   // iec 61937 syncword 2
> +    buf16[2] = 0x0001;   // data-type ac3
> +    buf16[3] = len << 3; // number of bits in payload

Since this patch applied, I'd like to introduce a little fix for
data-type-dependent bits when construct iec 61937 ac3 header. That's
the 8 to 10 bits of buf16[2], it should be the bsmod value from input
ac3 buffer. This could be fixed as:

     buf16[2] = 0x0001;   // data-type ac3
+    buf16[2] |= (uint16_t)(sh_audio->a_in_buffer[5] & 0x7) << 8; // bsmod
     buf16[3] = len << 3; // bits number of payload

This is according to IEC 61937-3. I checked it to verify why vlc's
source code write that byte with bsmod. Finally I found It indeed need
to write the bsmod there by the iec.

-- 
Ulion