[mythtv-users] chirping in recordings with pchdtv hd-3000's and 0.21

[Krzysztof Adamski]

On Wed, 2008-16-04 at 16:57 -0400, Tom Dexter wrote:
> On Tue, Apr 15, 2008 at 4:20 PM, Tom Dexter <digitalaudiorock at gmail.com> wrote:
> > On Tue, Apr 15, 2008 at 6:46 AM, Tom Dexter <digitalaudiorock at gmail.com> wrote:
> >  > >
> >  >  I occasionally get corruption in my recordings (for example due to OTA
> >  >  interference in bad weather)..the kind that causes temporary video
> >  >  pixelation etc.
> >  >
> >  >  Under 0.20.2 it seemed that, if anything, these would cause slight
> >  >  audio dropouts, and only rarely seemed to cause any significant audio
> >  >  noise.  For some reason under 0.21 virtually any corruption like this
> >  >  seems to cause full-scale audio chirps almost without fail.
> >  >
> >  <snip>
> >  >  Tom
> >  >
> >
> >  It appears that between 0.20.2 and 0.21 libs/libavcodec/ac3dec.c (part
> >  of ffmpeg) was radically re-written.  As a matter of fact it's about
> >  six times as long now.
> >
> >  I'll bet that's why it's handling things differently.
> >
> >  Tom
> >
> 
> ...(and in his best Austin Powers voice) YEA BABY!! :D
> 
> It looks like I have a fix.  It appears that in more recent versions
> of ffmpeg the libavcodec/ac3dec.c file has had some crc error checking
> added to address this.  The newer versions are quite different from
> the existing one, but the original discussion on the ffmpeg-devel
> list, including a proposed patch, starts here:
> 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-September/034883.html
> 
> If you follow that thread you'll see it discusses this very issue of
> getting serious pops from corrupted broadcast transport streams, and
> how some amount of errors are even expected in DVB.  I was able to
> hack together the following patch which is similar to the original one
> posted at the above link, only is unconditionally does the error
> checking regardless of the error_resilience specified by mythtv...I
> knew I wanted the error checking so I just made it unconditional.
> 
> Here's what my patch looks like (I've attached it as well):
> 
> 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 saved a recording for testing the other day that had corruption in a
> spot that I made note of.  Before the patch I'd get this in my
> frontend logs at that point:
> 
> 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 the awful chirps.  After installing with the patch, I
> get this in the logs at that same point:
> 
> 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
> 
> ...and only slight audio dropouts (silence) in place of the chirps...yes!!
> 
> I don't know that this patch is the ideal way to address it, but it
> certainly seems to work.  I'm going to post to the dev list about this
> one.
> 
> Tom

This is going to have an impact on the CPU usage, you are doing CRC
calculation on every block of data. It may be negligible but still some,
so maybe a way of turning it off would be a good idea.

K