[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

	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"

	- 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:


The content is old, but unfortunately still up to date because I
haven't had time to touch it for quite some time.


More information about the mythtv-dev mailing list