[mythtv] 0.21 and ffmpeg handling of corrupt ac3
digitalaudiorock at gmail.com
Fri Apr 18 18:57:36 UTC 2008
On Fri, Apr 18, 2008 at 1:59 PM, Marc Randolph <mrand at pobox.com> wrote:
> On Fri, Apr 18, 2008 at 12:30 PM, Scott D. Davilla <davilla at 4pi.com> wrote:
> > >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".
> Certainly nothing wrong with doing that, but doing a check at the
> decoder makes sense as well, at least to me. Corrupted data could
> come from other sources (the first one that jumps to mind is a
> front-end connected via a wireless network), could it not?
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
Good point. I would certainly hope that, were any option to
demux/decode and check video on the backend were added, that it would
be optional, for those who don't want to add any overhead to the
The audio only crc check on the frontend is actually fine for my
purposes. As I said, I can't detect any extra overhead from it. A
bit of video corruption here and there (some momentary pixelation for
example) doesn't bother me...but those full-scale chirps that could
fry tweeters are another thing altogether :D.
More information about the mythtv-dev