<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.
      &nbsp;This has lead to a lot of questions, some of which I'm pretty
      sure point to legitimate problems with the current code. &nbsp;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). &nbsp;However,
        all of the "Classic" commflag code treats the data as if it is
        8bpp (YUV420P is 12). &nbsp;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. &nbsp;It seems completely broken to me. &nbsp;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. &nbsp;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. &nbsp;Git history seems to show
        it hasn't had anyone really touch it since 2006. &nbsp;Is it dead?
        &nbsp;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 -&gt; 420x270). &nbsp;Since the player does
        this, these are scaled/blended so not all of the data is lost.
        &nbsp;This size&amp;data is used for logo detection. &nbsp;But for Scene
        Change and Blank Frames, the comm flagger then only uses every
        4th byte, ignoring 3/4 of the scaled down data. &nbsp;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. &nbsp;Anyone know if Mark
        plans to get back to that (perhaps he's busy with 0.26 at the
        moment)? &nbsp;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>