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

[Michael Niedermayer]

Hi

On Sun, Sep 02, 2007 at 03:21:44PM -0700, Trent Piepho wrote:
> On Sun, 2 Sep 2007, Reimar [iso-8859-1] D?finger 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.

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

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

i also can assure you the divx decoder trashes the image totally if feeded
with a damaged frame (ive tried it long ago) and it would certainly look
better if the frame would not be input into it but libavcodec does not
behave like that, it will detect the errors and only conceal the damaged
parts while using the undamaged ones, yes its not 100% but it provides
a much better image on average than droping the whole frame

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070903/3ba8bfc0/attachment.pgp>