[mythtv] Comm Flag questions/confusion

Bryan bryan at mlewallpapers.com
Tue Sep 4 01:07:24 UTC 2012


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.

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?

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?

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

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20120903/1c260508/attachment.html>


More information about the mythtv-dev mailing list