[FFmpeg-devel] [PATCH] AC3 decoder CRC check
Mon Sep 3 06:49:22 CEST 2007
Michael Niedermayer wrote:
> On Sun, Sep 02, 2007 at 11:12:42PM +0200, Reimar D?ffinger wrote:
>> 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.
More information about the ffmpeg-devel