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

[Trent Piepho]

On Mon, 3 Sep 2007, Michael Niedermayer wrote:
> On Sun, Sep 02, 2007 at 03:21:44PM -0700, Trent Piepho wrote:
> > 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.
>
> if a TS packet is droped the TS demuxer could possibly even pass this
> information to the decoder so it knows precissely which data is valid and
> which is missing thus allowing the ac3 decoder to decode the data which is
> intact

What often happens is that the TS packet is not dropped, but is corrupted.
Since the pid is wrong, it is not demuxed into the AC3 stream, and so from
the perspective of the AC3 parser a packet is missing.  Of course the TS
demuxer, using the continuity counter, could detect missing packets or
bursts of packets in a given PID, and tell upper layers about this.

That could make maintaining stream sync in face of errors much easier.

> and you are not speaking from experience with ac3 you speak from experience
> with a specific (crappy) ac3 decoder this has no relevance
> any sensible ac3 decoder provides some error resilience itself ether by

I'm talking about experience with what kinds of errors one gets from
digital broadcasts.

You could make a better AC3 decoder that deals with errors of a small
number of bits.  I'm saying that won't be worth much, because that kind of
error isn't very common.

The common error is missing TS packet(s) worth of data.

> using some advanaced algorithm or by just checking the crc and droping the
> frame, your claim that checking crcs and droping frames helps shows that
> the decoder is crap

Who said I checked CRCs and dropped frames?  I check CRCs, detect missing
TS packets, and pad and fill damaged AC3 frames.