[mythtv] 0.21 and ffmpeg handling of corrupt ac3

Tom Dexter digitalaudiorock at gmail.com
Wed Apr 16 21:31:14 UTC 2008


Hey folks...before I continue, as someone who just recently upgraded
to 0.21 under Gentoo, let me just extend a huge thank you for all the
work you do.  0.21 simply rocks.

Several of us on the users mailing list noticed that, after the 0.21
upgrade, the audio of recorded DVB broadcasts didn't appear to be
handling corrupt ac3 as gracefully as it used to.  Some degree of
corruption, especially with OTA recording is almost inevitable.

What we found was that in 0.20.2 the tendency when mythtv encountered
corruption in a DVB transport stream, more often than not, was for the
audio to drop out (brief silence) if anything.  However in 0.21, any
file corruption seemed to almost invariably cause full scale digital
chirps...the kind that can knock you out of your seat if you're
listening at any volume.  Here's the archive of the thread on -users:

 http://www.gossamer-threads.com/lists/mythtv/users/329267

I could see that between 0.20-fixes and 0.21-fixes,
libavcodec/ac3dec.c had obviously been totally re-written by the
ffmpeg devs.  After some poking around I discovered that newer
versions of ffmpeg have had crc error checking added to
libavcodec/ac3dec.c for this reason.  The original discussion on
ffmpeg-devel, as well as the original proposed patch starts here:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-September/034883.html

That thread seems to have a very heated debate about it for some
reason, but in any case it looks like newer versions do in fact have
error checking.  For my own purposes, I hacked together a modified
version of the original patch posted at the above link.  For
simplicity I made the check unconditional (regardless of
avctx->error_resilience).  That patch (designed for SVN 16944) looks
like this:

Index: libavcodec/ac3dec.c
===================================================================
--- libs/libavcodec/ac3dec.c
+++ libs/libavcodec/ac3dec.c
@@ -37,6 +37,7 @@
 #include "bitstream.h"
 #include "dsputil.h"
 #include "random.h"
+#include "crc.h"

 /**
  * Table of bin locations for rematrixing bands
@@ -1121,6 +1122,12 @@
         return -1;
     }

+    if (av_crc(av_crc8005, 0, buf + 2, buf_size - 2)) {
+        av_log(avctx, AV_LOG_ERROR, "CRC error\n");
+        *data_size = 0;
+        return buf_size;
+    }
+
     avctx->sample_rate = ctx->sampling_rate;
     avctx->bit_rate = ctx->bit_rate;

I had a recording that I had saved for testing with corrupt audio in a
known spot.  Without the patch I'd get this in my frontend logs:

2008-04-15 20:11:34.573 [ac3 @ 0xb73e3028]delta bit allocation strategy reserved
2008-04-15 20:11:34.573 [ac3 @ 0xb73e3028]error parsing the audio block

...along with absolutely awful chirps.  After applying the above patch
the same spot in the recording causes this in the frontend logs:

2008-04-16 16:31:19.787 [ac3 @ 0xb73e7028]CRC error
2008-04-16 16:31:20.535 [ac3 @ 0xb73e7028]CRC error
2008-04-16 16:31:20.706 [ac3 @ 0xb73e7028]CRC error

...along with no more than slight audio dropouts...big big improvement.

I'm not sure what the ideal way to implement this would be, but I
think many DVB users (especially us OTA users) would love to have this
one addressed.  I haven't logged any bug as yet.

Thanks again!

Tom


More information about the mythtv-dev mailing list