[mythtv] New Method for Commercial Detection.
lucas at mach8.nl
Tue May 2 18:23:45 UTC 2006
Robert Dunn wrote:
> This isn't as much of a problem as you would imagine, the reason this
> technique can work is because commercials repeat, where as programs do
> not. Even if someone were to submit keys for the latest episode of a TV
> Show. They wouldn't detect the program unless it aired again before the
> keys 'timed out' and were removed from the database. Over here there are
> very few TV shows which would have the same episode aired within a
> couple of weeks of each other.
Hmm, good point. I guess the worst thing that could happen is when
things like the intro animation of a
specific series gets flagged as commercial, as that does air over and
> In my embedded DSP device, I could generate keys and check a smallish database of keys (with no search optimizations at all) in real time. The largest time consuming thing is the checking of a database. The goal for my project I mentioned is to achieve commercial detection in real time, which depending on the number of keys needed I think should be achievable. I dont know much about MythTV (im slowly learning) but is the commercial flagging done in real-time or as a post processing effect?
That is at the CommDetector's implementation's disgression. If the user
has configured commercial detection to run in realtime, it will run in
Currently we only have one commdetector implementation, and that one
will lag behind a few minutes (orso, I believe this time changed recently),
and send updated commercial breakmap events to the frontend & stores
them in the database, while it is finding them.
I've been working for ages on a different commdetector implementation
(far from done, might very well never reach that state, fun
needs information from the entire recording before being able to make a
decent decision on what is a commercial and what not.. In this case I
it analyze the recording "live", and only when everything is analyzed,
do some logic on it, and send updates...
If you want to get really fancy, your commdetect implementation could
instantiate a classiccommdetector in case we're flagging a live
when its done, and hopefully has produced at least a good guess on the
commercials, do a "slow" postprocess flagging that would supposedly return
Looking at the ideas so far for the new method, I don't see any reason
why it might not work in livemode though...
By the way, besides the presence of the paper describing how to
effectively take audio fingerprints, there is nothing that would stop
combining these with a video fingerprint right?
More information about the mythtv-dev