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

Reimar Döffinger Reimar.Doeffinger
Sun Sep 2 23:12:42 CEST 2007

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.

> The proper thing to do is to check the CRCs, and if the first is bad fill the
> frame with silence or use some kind of "scratch fill" algorithm.  If just the
> second is bad, you can still decode some audio I think.

Well, that sure would be one way to deal with it. Whether it is the best
is another question - it certainly isn't for MPEG-video (which I know is
not comparable)...

> Either way, after a bad CRC one should check the frame syncronization.  It's
> common with digital broadcasts to drop packets, causing AC3 frames to be 184 *
> X bytes short.  If the CRC fails and the next frame's AC3 sync word isn't in
> the expected location, it's a good idea to search backward from the expected
> end of the frame looking for an AC3 syncword.

Hmm.. doesn't it make more sense to search forward from after the start
of the last frame? Even so there still is the problem if resynching
reliably so a "first pass" that searches for something with a valid CRC
first would probably be good. And it hopefully can use the same code as
the probe function...

Reimar D?ffinger

More information about the ffmpeg-devel mailing list