[FFmpeg-devel] [PATCH] Add a parser for DNET (byte-swapped AC3).

[Justin Ruggles]

On 03/03/2011 12:48 AM, Reimar D?ffinger wrote:

> On Wed, Mar 02, 2011 at 07:01:40PM -0500, Justin Ruggles wrote:
>> On 03/02/2011 06:08 PM, Reimar D?ffinger wrote:
>>>>> For example, I think it would be fine for the AC3 parser to detect byte
>>>>> order and then not accept switching byte order during parsing.  This
>>>>> would mitigate the false positive probability increase for all but the
>>>>> first frame, which is ok with me.
>>>>
>>>> Why would you want to do this? Making things difficult just for the heck of it or what?
>>>> There is _no_ AC3 decoder that even tries to do this.
>>>> Just to avoid a CODEC_ID? We do have one for each raw format, including differently swapped ones. And you would be ready to accept an error rate of 1:64000 just for that?
>>
>> For the first frame, yes. It's not that much different than the current
>> probability.  When calculated over the whole stream, yes it's
>> significant, but for just 1 frame it's not.
> 
> No, it is not comparable at all.
> In the current situation we also take the length into account, which
> means that once we locked onto a pattern we are likely we are likely
> to keep onto it, and if we get it wrong for the first frame (or any frame)
> we get another chance for the next one.
> Now if we handle both formats there's two possibilities:
> 1) we allow the detection to change any frame. Here we have the advantage
>    of being able to recover, however due to the specific pattern of the
>    AC-3 header, one 0-byte padding + a byte swapped header will look exactly
>    like a non-byteswapped header (at least I think).


Not exactly, but it's still not good. The header sync word is 0x0B77 (or
0x770B for byte-swapped) so if a 0x77 byte comes before a normal header
it will be detected as a byte-swapped frame if the other 1.5 bits of the
header that are checked don't fail.

So that means there is a 1:256 chance of a misdetected sync word if the
parser is fed a partial first frame.  The last 2 bytes of an AC3 frame
are a CRC-16 so the last byte is pretty much random.  The encoder can
typically avoid the CRC being 0x0B77 by flipping a bit that's used for
this purpose, but this is only optional per the spec.

> 2) we lock onto a specific format. Here getting it wrong for the first
>    frame will break playback permanently, which as said is significantly
>    different from the current behaviour.
>    And when starting playback of a raw AC3 or MPEG-* we will often end up
>    in the middle of a frame, so that 1:whatever chance seems quite significant.

I'll give up on auto-detection for now then.  The parser would need to
be more robust, like using a chain of matching CRC's as is done in the
FLAC parser.  And that's a lot of added complexity for something that's
only slightly useful.

-Justin