[mythtv] Comm Flag questions/confusion

[Chris Pinkham]

* On Tue Sep 04, 2012 at 12:53:14PM +1000, Mark Spieth wrote:
> On 9/4/2012 11:07 AM, Bryan wrote:
> >2) The comm flag code passes kDecodeLowRes to the player, which causes 
> >the frames coming out of the player to be 1/4 their original size 
> >(1920x1080 -> 420x270).  Since the player does this, these are 
> >scaled/blended so not all of the data is lost.  This size&data is used 
> >for logo detection.  But for Scene Change and Blank Frames, the comm 
> >flagger then only uses every 4th byte, ignoring 3/4 of the scaled down 
> >data.  Could it be that comm flag's build in "every 4th pixel" is 
> >supposed to do the same thing as kDecodeLowRes, and thus using both at 
> >the same time was never intended?

> I read somewhere that this could be why logo det doesnt work very well 
> any more.

Yes, the horizontal and vertical spacing was put in to speed up flagging.
There's no need to check every single pixel in a 1920x1080 frame, so the
code may only check one out of every 100 for some things.  If you look in
ClassicCommDetector::Init(), around line 209 you'll see a group of 'if'
statements that set horizSpacing and vertSpacing variables based on
the number of pixels in the frame.  Keep in mind, this code was created
back before everyone had High Definition, most people had PVR-250 or BTTV
cards at the time, so that's where this scaling comes from.  If the 1/4
decode size is coming into play here, it could mess with the flagging
accuracy, this was mentioned when the low res decode option was being
discussed originally.

ClassicLogoDetector::DetectEdges() does not use the horizSpacing and
vertSpacing from ClassicCommDetector::Init(), but I think DetectEdges
could be affected by the low res decode option.  Decoding at 1/4 the
frame size will make the logo blocky and give it less edges to work
with.  A long time ago when I wrote that code, it had an option to
create an X window to display the Y data from the frame and highlight
the edges that were detected, but I ripped that out as it got harder to
maintain.

> Another thing Im going to try is to CRC frames (Y only) and hash them 
> for frequency. This assumes the digital frames will be identical which 
> may not be true. The aim of this is to match non blank frames during 
> silence.

This is essentially what the Scene Change histogram does but a CRC would
be quicker if it worked.  Rather than computing CRC for the frame, the
adjacent histograms could be compared to see how many frames were
repeated.  This is a big reason why the current system is designed
around weights.  Some areas may have still frames instead of blank
frames between shows and commercials.  Others might have still frames
with a spinning logo which would break any still frame detection.

Speaking of logos, here is another thing that has broken logo
detection.  A lot of channels will have either an animated logo or
two different logos or a still logo that starts out animated.  Detecting
these is harder and the reason why the current flagger looks at blocks
of video.  If the logos don't startup exactl when the show starts and
disappear exactly when the show ends, you can't use those start/end
frames as references, you can only use what's inbetween them as a
guide to indicate that block is probably part of the show.  Some
networks in the U.S. also have the habit of putting one logo on top
of another.  I've seen local station logos on top of network logos and
I've seen the network stomp on top of their own logo when running a
animated graphic at the bottom of the screen advertising some other
show coming up either after the show that's on or as part of a promo
for a new show.  Sometimes they even have people walking across the
screen at the bottom as part of these advertisements.

--
Chris