digitalaudiorock at gmail
Apr 16, 2008, 1:57 PM
Post #8 of 14
(2667 views)
Permalink
|
|
Re: chirping in recordings with pchdtv hd-3000's and 0.21
[In reply to]
|
|
On Tue, Apr 15, 2008 at 4:20 PM, Tom Dexter <digitalaudiorock [at] gmail> wrote:
> On Tue, Apr 15, 2008 at 6:46 AM, Tom Dexter <digitalaudiorock [at] gmail> 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
|
mythtv-0.21-ffmpeg_ac3_crc.patch
