[mythtv] mythcommflag patch
Robert Tsai
mythtv at tsaiberspace.net
Wed Oct 10 03:23:55 UTC 2007
On Tue, Oct 09, 2007 at 04:16:24PM -0400, Mark Steckel wrote:
> At 03:17 PM 10/9/2007, you wrote:
> > > The following diff corrects a bug in mythcommflag
> >
> >Mark, you should probably post a ticket to Trac ( http://svn.mythtv.org/
> >) so this doesn't get lost. See, also,
> >http://svn.mythtv.org/trac/wiki/TicketHowTo
>
> Thanks. Will do.
>
> btw, I'm planning to work with mythcommflag for a project and was
> wondering if anyone on the list is the "go to" person for questions
> about it. For instance, what is the history of the second set of
> detectors that seem to be very similar (identical?) to the first
> set?
The second set of detectors ("Experimental") was writen by me.
Basically, it works better for me, for my OTA HD in the US. I can't
claim that it is necessarily better or worse than the "Classic" one.
Some differences from a developer's point of view (I assume Chris will
correct me if I'm wrong):
- Video analysis:
- The "Classic" detector stores all of the strategies' state
in the per-frame data structures (FrameInfoEntry). If you
want to add a new strategy, you add some new fields. Some
analyses have inter-frame dependencies (analysis of some
frame depends on the analysis of the preceding frame).
- The "Experimental" detector kind of flips things around;
each type of analysis is responsible for computing its own
information about each frame (although it may build on top
of other strategies; see BlankFrameDetector.h for an
example). All frames are analyzed pretty much independently
of each other (there are obvious dependencies if two
strategies both need to know common information like the
aspect ratio of a frame).
Much of the video analysis (blank-frame detection, logo
detection, etc.) is implemented separately by each detector.
The "Classic" detector has more speed optimizations (not
having to examine every pixel in each frame, etc.) that could
be but are not implemented in the "Experimental" detector.
IMHO, the architecture of the "Experimental" detector is
better (this is a statement of the architecture of the code,
not of any imputed accuracy of the implemented strategies),
since all frames are analyzed independently of each other. For
example, it would be rather fully-parallelizable if made
multi-threaded.
However, this per-frame independence probably also makes it
more memory-hungry (it doesn't/can't collapse any analysis
state across consecutive frames).
- Commercial "scoring":
- The "Classic" detector takes all of the per-frame
information, assembles "blocks" of continuous similar
frames, and gives it a ham/spam score based on the each
analysis. Blocks with a score exceeding some threshold are
"ham", blocks with a score below that threshold are "spam"
(commercials).
- The "Experimental" detector lets each kind of analysis
attempt to independently arrive at ham/spam verdicts, and
then attempts to aggregate them all together (see
CommDetector2::computeBreaks). For example, if everything is
turned on, it basically does logo matching, then nudges the
commercial boundaries based on things like aspect ratio
changes and/or blank frames, so it's not really
"independent" analyses.
I believe the scoring technique in the "Classic" detector is
the much better way to go.
This was not done for the "Experimental" detector because of
the smaller number of available analyses; it is still feasible
to combinatorically combine the results together depending on
which analyses are active (three independently-enabled
analyses yield 8 possible ways to compute results). But if any
more strategies are implemented, a scoring technique will
become necessary.
You can read about the "Experimental" flagger starting here:
http://www.mythtv.org/wiki/index.php/User:Rtsai1111
The content is old, but unfortunately still up to date because I
haven't had time to touch it for quite some time.
--Rob
More information about the mythtv-dev
mailing list