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

Trent Piepho xyzzy
Sun Sep 2 22:53:15 CEST 2007


On Sun, 2 Sep 2007, Reimar [iso-8859-1] D?ffinger wrote:
> On Sun, Sep 02, 2007 at 06:32:26PM +0100, M?ns Rullg?rd wrote:
> > Andreas ?man <andreas at olebyn.nu> writes:
> > > M?ns Rullg?rd wrote:
> > >>
> > >> I reckon the decoder will notice if the frame is damaged anyway, and
> > >> see no reason to explicitly check the CRC.
> > >
> > > I must say i disagree here.
> > >
> > > I've uploaded a sample to incoming/ac3-seriously-damaged recorded
> > > from a DVB broadcast. The recording has deliberately poisoned with
> > > transport stream packet drops to make the issue more clear.
> > > Normally you would not have this rate of errors of course.
> > > But remember that DVB specifies that one error per hour is acceptable,
> > > and having these type of clicks every now and than makes listening
> > > to TV an unpleasant experience.
> > >
> > > Anyway, one can notice that all the clicks and blipps goes
> > > away completely with the CRC check.
> >
> > In that case I say the AC3 decoder needs to be improved to reject
> > these damaged frames.
>
> Especially since the CRC thing assumes the best solution to even a single
> flipped bit (possibly even in the CRC itself!) is to just drop the whole
> thing (at least unless someone implements something better in lav*).
> Though, actually if there is a way to _disable_ error resilience it
> might make sense to enable this check in that case...

AC3 frames have _two_ CRCs.  The first CRC protects the first part of the
frame, and the second CRC protects the second part.  Since the AC3 CRC is
designed to start and stop at 0, they also protect the whole frame.  If the
first crc is ok, but the second is bad, it should still be possible to decode
some audio and determine the frame length.

If the crc is bad, the frame is useless.  It's a CRC, not Reed-Solomon, you
can't correct the bits.

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.

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.




More information about the ffmpeg-devel mailing list