[mythtv] Comm Flag questions/confusion

[Mark Spieth]

On 9/4/2012 11:07 AM, Bryan wrote:
> I've been having some minor issues with commflagging on 0.26 (don't 
> worry, nothing newly broken from 0.25, just a few lingering problems), 
> so I decided to take a look in the code.  This has lead to a lot of 
> questions, some of which I'm pretty sure point to legitimate problems 
> with the current code.  I'd appreciate it if anyone can answer any 
> questions and/or help me figure out whether anything here worth my 
> time to create patches for (and thus someone else's time to review and 
> pull).
>
> 1) It appears that all video that comes out of mythplater is YUV420P 
> (and commflag will refuse to run if it isn't).  However, all of the 
> "Classic" commflag code treats the data as if it is 8bpp (YUV420P is 
> 12).  I'm not entirely familiar with how YUV works, but even assuming 
> the lower 8 bits represent something useful, roughly half of all 
> access of the data made by the comm flag code will be to bytes which 
> contain half of 2 different pixels.  It seems completely broken to me. 
>  Probably all of the data examined by commflag needs to be Grayscale 
> 8bpp (PIX_FMT_GRAY8), but it definitely needs to be 8bpp.
>
it is my understanding, the format is Y (8bpp) then U (8bpp at 1/4 
scale) then V (8bpp at 1/4 scale). the pixels are not interleaved as in RGB.
blank frame is done on the Y part only.

> 1a) The "CommDetector2" code seems like it may convert to grayscale 
> 8bpp.  But that code isn't connected to any commandline options or any 
> GUI setup anywhere that I've seen... so it is likely never used by 
> anyone.  Git history seems to show it hasn't had anyone really touch 
> it since 2006.  Is it dead?  Why is it still in there if it's dead?
I couldnt get this to work either. from my look at the code, it lost its 
fuzzylogic-ness which made the original so good.
>
> 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.
> 3) If commDetectBorder was ever 0 it would cause some out of bounds 
> conditions and probably crash the comm flagger.
>
> 4) I saw the "NextgenCommDetector" patches in #10793, but they haven't 
> been touched in a few months.  Anyone know if Mark plans to get back 
> to that (perhaps he's busy with 0.26 at the moment)?  I messed with 
> them a little bit but didn't have a lot of luck, then I got distracted 
> with YUV420....
>
Sorry Ive been meaning to get back to it. Too many other things on my plate.
seems to work quite well for me and if/when I get logo det working it 
will be even better. There are problems identifying ads. Currently it 
all hinges on matching individual ad durations.

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.

Also the commflagger still crashes sometimes and I havent got a handle 
on that yet either. This is not deterministic on the same recording.

cheers
mark
> Thanks!
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20120904/99707144/attachment.html>