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

Trent Piepho xyzzy
Mon Sep 3 00:21:44 CEST 2007


On Sun, 2 Sep 2007, Reimar [iso-8859-1] 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.

True, the error could be a in a padding bit or something else irrelevant.
But, suppose you do decode the damage frame and get some audio.  How can you
know if this audio is correct, or close to correct, and not annoying noise?

This is compressed data, so most of the bits are supposed to be information,
not redundant.  If bits are bad, it's very much more likely they are
important, and that filling the damaged frame using scratch concealment will
be better than playing whatever it was that the decoding algorithm produced.

Another thing to consider is that digital broadcasts are a common source of
damaged AC3 audio.  All digital broadcasting schemes have error detection and
correcting designed into their physical layer.  If there were just a few
flipped bits, it would be corrected.  It's only when you have a significant
amount of error that you see CRC failures in the AC3 frames.

I'm speaking from experience here.  In order to improve reliability of
playing/transcoding ATSC broadcasts, I wrote an AC3 error checker and
re-synchronizer.  Errors almost always manifest themselves as some multiple of
184 missing bytes, due to a TS frame(s) being dropped.

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

Usually, the number of dropped bytes is small (184 or 368) compared to the
size of an AC3 frame, so the sync word is usually closer to the end than to
the beginning.  Since sync word emulation is possible, the less searching the
less the chance of finding a emulated sync word.  Though in practice, I doubt
it makes any significant difference.

Of course, if you don't find a sync word after searching backward from the
expected end of the frame, then you search forward from the expected end.  The
difference is that if you find a syncword during the backward search, you
(probably) have one corrupted frame.  If you find it during the forward
search, you probably have 2+ corrupted frames.




More information about the ffmpeg-devel mailing list