[mythtv] mythcommflag patch

[Mark Steckel]

Thanks for the detailed info.

Mark


At 11:23 PM 10/9/2007, you wrote:
>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
>_______________________________________________
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev