[FFmpeg-devel] [PATCH] Add a parser for DNET (byte-swapped AC3).
Thu Mar 3 18:01:47 CET 2011
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.
More information about the ffmpeg-devel