[mythtv] New Method for Commercial Detection.

Lucas Meijer 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 
over again.

> 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 
realtime.
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 
nonetheless), that
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 
just let
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 
recording, and
when its done, and hopefully has produced at least a good guess on the 
commercials, do a "slow" postprocess flagging that would supposedly return
better results.

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 
you from
combining these with a video fingerprint right?


Bye, Lucas


More information about the mythtv-dev mailing list