[mythtv] [mythtv-commits] mythtv/master commit: 72d437001 by Daniel Thor Kristjansson (daniel-kristjansson)

[f-myth-users at media.mit.edu]

    > Date: Mon, 12 Dec 2011 22:54:03 -0500
    > From: Daniel Kristjansson <danielk at cuymedia.net>

    > On Mon, 2011-12-12 at 21:57 -0500, f-myth-users at media.mit.edu wrote:
    > > > Date: Mon, 12 Dec 2011 23:01:46 +0000 (UTC)
    > >     > From: MythTV <noreply at mythtv.org>
    > >     > Adds 'damaged' video property for poor recordings.
    > > I'm not running master, so I can't submit code for this yet, but may
    > > I suggest that another quality metric is whether or not the recording
    > > contains EAS bursts?  This is a -constant- problem on my Comcast feed,

Oh, and also -silences-.  See below.

    > I hate to contradict what was said in the ticket but since this
    > requires decoding the audio it's probably best done in an external
    > program managed by mythtv like how real-time mythcommflag works.

I'm not sure who wanted it integrated; that wasn't my comment in the ticket. :)

One of the features about having it -not- integrated is that you can
run the code on any machine that can see the recording.  It would make
sense to run it on the machine whose local disk is accumulating it
(both to minimize network and to grab it from the file cache, since
you're only a few seconds behind), but you -could- do it anywhere.
[I also did it that way because I didn't want to have to keep patching
it into myth forever for what I assumed would be a local patch; since
it just reads a file, it doesn't care about myth, though telling myth
about errors would of course rely on knowing that version's API.]

The code consumes about 1.5% of a 6-year-old CPU per stream being
recorded, and 90% of that is in mplayer.

    > That way libav crashes don't take down the backend. Other than that
    > I think this is a great idea.

Thanks.  Good to know.

The way my code works is that it runs the recording file through
mplayer to extract the audio, then does the signal processing on a
low-sample-rate, low-fidelity audio stream.  Since mplayer is reading
the stream as it comes it, it can give real-time notification of the
EAS toneburst, so you can know long before the recording is finished
if it got hit.  [And it looks for the pattern of the tones, so someone
playing a trumpet doesn't false-trigger it.]

It also looks for -silences-, in a configurable way, so you can detect
cases where the audio is simply missing.  This happens more often than
one might like---whether it's Comcast occasionally dropping audio for
a few minutes, or one of my local PBS stations that used to transmit
totally frozen video for 20 minutes at a time [failing equipment, I
assume], or something in the headend that used to display a bouncing
-screensaver- for the entire program, or a cable box that just drops
out for a while, detecting the missing audio has been -really- handy.
It's configurable because some stations -never- transmit dead air, so
even 30 seconds is known to be a disaster, while some film channels
might have silent or very quiet audio for minutes at a time and that's
just the way the movie was done.  The silence-detection starts from a
configurable level and then keeps an exponentially-averaged value; if
that average drops too low for too long, you have a problem.  [The
code is very well-commented; read that for the algorithm.]

    > PS I wouldn't be opposed to storing recording quality metrics in
    > the DB, I just didn't do it in those commits because it wasn't
    > necessary when everything is handled in the recorder. With an
    > external process that might be the easiest way to handle the
    > interprocess communication and would be consistent with how
    > mythcommflag works.

That sounds good to me.  It would also make it easy for user-level
tools to use an API against that to tell the user things, including
knowing for several reasons the recording might be bad ("I saw a gap
-and- there was an EAS burst", for example :)

It would be -really- useful because then easy SQL queries can tell you
things like, "What times of day do I get the most dropouts?" which
might tell you a lot about your antenna or something.  That's one
reason I also -really badly- want the tuner number recorded in the
DB, rather than assuming the user has (a) set logging high enough,
(b) saved all his logs forever, and (c) wants to grep the data back
out of those logs.  Just storing the tuner number in oldrecorded is
-much- more straightforward.