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

[Reimar Döffinger]

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).
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.

Unfortunately my patch was completely broken, for the DNET in RM sample a parser
isn't really needed thus I didn't notice that during my tests it was never used.
Either way, supporting the byte-swapping in the decoder probably would be a good thing,
since you think it is easy to do I'll probably try to implement it so I can test
this also with the FFmpeg Real demuxer.