[FFmpeg-devel] [PATCH] AC3 decoder CRC check

[Justin Ruggles]

Michael Niedermayer wrote:
> Hi
> 
> On Sun, Sep 02, 2007 at 11:12:42PM +0200, Reimar D?ffinger wrote:
>> Hello,
>> On Sun, Sep 02, 2007 at 01:53:15PM -0700, Trent Piepho wrote:
>> [...]
>>> If the crc is bad, the frame is useless.  It's a CRC, not Reed-Solomon, you
>>> can't correct the bits.
>> That's nonsense. I do no know the details of AC-3 to know how likely it
>> is, but the damage might be completely irrelevant (e.g. one of the 16
>> bits of the CRC damaged and nothing else) or at least hardly noticable.
> 
> also all data before the damage is ok, in video codecs its much better to
> guess where the error is and discard the data afterwards instead of discarding
> the whole slice
> and like reimar i dunno the details of ac3 ...

I know the details of AC3 pretty well, and using both CRC's would only 
be slightly helpful.  If the first CRC is a match, you can at least 
count on correct information in the header, which will give you the 
frame size, channels, samplerate, etc...  Block boundaries within a 
frame are not equal though, so the decoder would have to keep track of 
how many full blocks fit within the first 5/8 of the frame and silence 
any remaining blocks if the 2nd CRC doesn't match.  The 2nd CRC applies 
to the whole frame, so you still get pretty good error resilience if you 
ignore the 1st CRC.

Someone mentioned that 1 bit probably wouldn't make a difference, but in 
AC-3 just 1 bit can make a big difference.  There are no fixed or easily 
detectable block boundaries, only frame boundaries, and most of the 
parsing depends on several coded values, so if it's off by even 1 bit, 
you very often end up with either an error (if you catch it) or noise.

CRC checking aside, the AC-3 decoder can definitely be made better as 
far as error detection.  It will probably slow down decoding a bit 
though.  The AC-3 specification actually gives a list of error 
conditions that can be checked for.

-Justin