[mythtv] 0.21 and ffmpeg handling of corrupt ac3

[Scott D. Davilla]

>On Wed, Apr 16, 2008 at 5:31 PM, Tom Dexter 
><digitalaudiorock at gmail.com> wrote:
>>  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
>>
>
>It occurred to me that, if at any point mythtv uses a newer version of
>ffmpeg, this issue will pretty much fix itself.  In any case, if
>anyone thinks I should log a bug, and maybe post my patch for anyone
>looking for a quick fix, let me know.  I already posted it to the
>users list.

Just a though, but how about fixing these problems at the source 
before they get propagated to disk at the backend. For DVB and 
HDHomeRun, the backend load is very light and since one would just be 
doing crc checks and fixes, this would not add much to the backend 
load.

That way, the recorded file is guaranteed "clean". Sort of solve the 
problem at the source and eliminate "garbage in garbage out".