<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 9/4/2012 11:07 AM, Bryan wrote:<br>
</div>
<blockquote
cite="mid:CAPmk6HfFSyHcaS3Jp_6YSCaOpUAMTf9UAsHjPi5UQgkDD+aajw@mail.gmail.com"
type="cite">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).
<div>
<br>
</div>
<div>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.</div>
<div><br>
</div>
</blockquote>
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.<br>
blank frame is done on the Y part only.<br>
<br>
<blockquote
cite="mid:CAPmk6HfFSyHcaS3Jp_6YSCaOpUAMTf9UAsHjPi5UQgkDD+aajw@mail.gmail.com"
type="cite">
<div>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?</div>
</blockquote>
I couldnt get this to work either. from my look at the code, it lost
its fuzzylogic-ness which made the original so good.<br>
<blockquote
cite="mid:CAPmk6HfFSyHcaS3Jp_6YSCaOpUAMTf9UAsHjPi5UQgkDD+aajw@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
</blockquote>
I read somewhere that this could be why logo det doesnt work very
well any more.<br>
<blockquote
cite="mid:CAPmk6HfFSyHcaS3Jp_6YSCaOpUAMTf9UAsHjPi5UQgkDD+aajw@mail.gmail.com"
type="cite">
<div>3) If commDetectBorder was ever 0 it would cause some out of
bounds conditions and probably crash the comm flagger.</div>
<div><br>
</div>
<div>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....</div>
<div><br>
</div>
</blockquote>
Sorry Ive been meaning to get back to it. Too many other things on
my plate.<br>
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.<br>
<br>
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.<br>
<br>
Also the commflagger still crashes sometimes and I havent got a
handle on that yet either. This is not deterministic on the same
recording.<br>
<br>
cheers<br>
mark<br>
<blockquote
cite="mid:CAPmk6HfFSyHcaS3Jp_6YSCaOpUAMTf9UAsHjPi5UQgkDD+aajw@mail.gmail.com"
type="cite">
<div>Thanks!</div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mythtv-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mythtv-dev@mythtv.org">mythtv-dev@mythtv.org</a>
<a class="moz-txt-link-freetext" href="http://www.mythtv.org/mailman/listinfo/mythtv-dev">http://www.mythtv.org/mailman/listinfo/mythtv-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>