<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    NV12 is similar to I420 (or YUV420, if you prefer), so it is 12 bit
    per pixel, 8 for luminance and 4 for CrCb (or U and V if you
    prefer). See <a class="moz-txt-link-freetext" href="http://www.fourcc.org/yuv.php#NV12">http://www.fourcc.org/yuv.php#NV12</a>.<br>
    Obviously, "4 bits for CrCb" means that each byte is used for 4
    pixels (a 2x2 quad), and so NV12 is a planar only format.<br>
    <br>
    So: 640 x 480 x 1,5 = 450 kBi = 3.51 Mbi uncompressed => 3.51 Mbi
    / 160 kbi = 22,5 times.<br>
    <br>
    I suggest to render the stream for the luminance plane only (like
    old TV sets!!): if you get a good output, the problem is the way the
    renderer works on the U and V plane.<br>
    <br>
    <br>
    Regards,<br>
    <br>
        Renato<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Il 04/01/2013 13.49,
      <a class="moz-txt-link-abbreviated" href="mailto:temp2010@forren.org">temp2010@forren.org</a> ha scritto:<br>
    </div>
    <blockquote
cite="mid:CAK0dNZjH2pw0=C-i42NP=y1PSmzazuqm_NkEbupw4cfNMGyiCA@mail.gmail.com"
      type="cite">Thanks very much for your help, Ross.
      <div><br>
      </div>
      <div>BACKGROUND: (CLARIFICATION ONLY) Indeed I only have one
        thread calling doEventLoop().  That's all I meant by my
        penultimate background sentence.  The last background sentence
        points out a separate thread for MF, that's independent of
        Live555, and is in fact the thread taking advantage of the one
        exception within Live555: calling triggerEvent().</div>
      <div><br>
      </div>
      <div>FOLLOWUP QUESTION: Having incorporated your question one
        answer, my output is better and now only "very poor" rather than
        "horrible".  My uncompressed stream is 640 x 480 x 30fps.  It
        passes through NV12 format, which when considered as YUV I think
        has about 16 bits of info per pixel (8 bits for Y, 8 bits for
        UV, like YUV422).  So an uncompressed 640 x 480 frame should
        have nearly 5Mbits of info.  However, the compressed frames I'm
        sending to Live555 are generally 160kbits each (after an initial
        384kbit frame).   I realize you're not responsible for MF, but
        perhaps you can give your opinion, please. This suggests to me
        that my MF H.264 encoder is compressing roughly 5Mbits/160kbits
        = 31 times.  Perhaps my remaining "very poor" quality is because
        this is too much compression.  I reconfigured the encoder for 10
        times the average bit rate, but this typical 160kbits/frame
        output size didn't really change.  DO YOU AGREE that I ought to
        be able to increase encoder output quality by increasing average
        bit rate, and that the 160kbits per compressed frame should rise
        toward 5Mbits?</div>
      <div><br>
      </div>
      <div>Thanks again.</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div><br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
live-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<a class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>