[mythtv-users] Detecting missed channels changes via logos

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

Here's a wacky idea, tossed out in case it inspires someone to
experiment with it:

We keep hearing about occasional missed channel changes.  Sure, it's
great if whatever bug causes failures gets stepped on, but sometimes
that's never possible, or takes an enormously long time.  And often a
missed channel change means that the show is gone for good by the time
the failure is detected (after all, the whole point of a PVR is that
it records -unattended-; if you have to babysit it so it doesn't miss
a broadcast that isn't repeated, it's lost a lot of its utility).

Myth can already identify logos as part of the commflagger, so how
about something that monitors an in-progress recording until it sees
a logo that resembles what it's looking for, and either alarms or
retries the channel-change if one doesn't come along by some point?
This could presumably leverage on the existing commflagger code, with
perhaps some optimizations (like starting to look immediately upon the
start of the recording, rather than delaying 5-8m as the current
commflagger does to build up a big buffer) to make it more likely
to be useful.

Since we're only expecting a single logo (or a short animation) and
we already know what logo to expect, this seems more computationally
feasible than it'd be if the task was "identify what channel we're
actually on from its logo"---if we see no logo, then we're in an ad
(or, for stations like IFC that display it only part of the time,
we're in the logo-free interval), but if we see something that looks
like a logo but it matches what we expect very poorly, we're probably
on the wrong station.

Once we see the correct logo for this channel, we stop looking, so
this need only run for the first few seconds/minutes in general.

Even better, this could be trained---in the assumption that -most-
channel changes are actually correct, we could fairly quickly build up
a selection of logo images for each given channel (and store 'em in
some table in the DB, presumably) and only try to do detection once
enough confidence has been established in the logo itself.  The
training can be done offline, e.g., asynchronously from actually
capturing, so it can be done in the background and be arbitrarily
computationally expensive.

For shows that are only broadcast once, simply starting a few minutes
early would give the detector enough time to know it's on the right
channel and try the channel change again if it's not; this might be
fairly natural if you routinely start early anyway to compensate for
clock skew between Myth and the broadcaster.

For shows that are repeated, a failure should cause the scheduler to
try to snag another copy (but continue recording this one, just in
case the detector blew it; I'm not sure in that case if it should try
to retune or just leave well enough alone in case the detector is
wrong and the channel was actually correct).  [This "try again on
failure" is a generalized ability that would be a good piece of
automation to have---that way, -any- error (e.g., spuriously-closed
I/O that had to be reopened, tuner lost lock, audio was missing,
broadcaster aired nothing but black video, etc etc) can be
automatically retried, hopefully before the next repeat; waiting for
the user to notice might mean that the last repeat has already
occurred.]

P.S.  I'm assuming that image analysis is the best we can do.
OTOH, if some of the digital streams have the callsign or channel
number or somesuch embedded in the data, then that could presuambly
be checked directly and at much lower computational expense and
complexity.  But that wouldn't help SD streams at all, of course.
[Or could broadcaster info be embedded in line 21 or some similar
line in NTSC?  I'm not sure how common this is.]