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

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

    > Date: Tue, 13 Dec 2011 07:29:16 -0500
    > From: "Brian J. Murrell" <brian at interlinx.bc.ca>

    > On 11-12-12 10:54 PM, Daniel Kristjansson wrote:

    > > 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.

    > And that's the key point.  Now there are two (or more) processes burning
    > CPU decoding the same audio/video stream.  And more might come.

...except the particular case under discussion (EAS/silence detection)
is -not- decoding video.  It's just pulling out audio.  That's a very
low-impact use (< 1.5% per SD stream on a 6-year-old CPU) and, if it's
happening close to real-time, just gets the input from the file cache.

Now, if there are -two- plugins that both want audio to do analysis
on, I'd recommend that they share the work, since mplayer's audio
extraction is 90% of that admittedly tiny amount of work.  They'd
have to agree on bitrates, though---I only need 16-bit 8kHz mono,
IIRC, whereas other analyzers might want to ensure that you didn't
just lose a stereo channel from a loose RCA connector or something...
The resulting API complexity just might not be worth it.

    > It seems to make sense to me to structure one decoding process (i.e.
    > "mythcommflag") which hands the decoded stream(s) on to a stack of
    > plugins to process however they want.

For video analysis, I agree, assuming again that all the plugins
can agree on what they want, and assuming that decoding the video
is the CPU-intensive part---I rather suspect it might be the actual
analysis after the decoding, but I've never profiled any of this,
and of course it depends greatly on the type of stream you're recording.

But mythcommflag throws away the audio, so attempting to roll EAS into
mythcommflag doesn't gain you anything but a process slot.  (Also, you
can run EAS/silence-detection even if you're not commflagging---I
never commflag commercial-free channels, but I still want failure
detection.)

P.S.  Some of the complexity of my code was detecting that we were
recording at all, so we can start following the stream---it involved
watching the filesystem etc.  I could have used inotify, but that
has its own issues.  A somewhat-better rewrite would instead use
the event system, but that didn't exist when I originally wrote this.
That would be more elegant that the looping bash script I used.