<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
>Do you mean going into my MF H.264 encoder? You must. <br>
<br>
Oops, no, not really! I rewrite my suggestion (the previous one is
good when working at the receiver side):
*grab* the stream for the luminance plane only (like old TV sets!!):
if you get a good output, the problem is the way the *encoder* works
on the U and V plane (or what you are guessing it likes to be fed
in).<br>
<br>
So, I mean to memset to 0x80 all the U and V bytes of the grabber
output (see <a class="moz-txt-link-freetext" href="http://www.vidcheck.com/whitepapers.asp">http://www.vidcheck.com/whitepapers.asp</a> to know why 0x80
and not 0x00, which would give the default green color).<br>
<br>
Obviously this test works only if the decoder input must be a planar
format; in case of a packed format (YUV422), it will fail and you
have to manage what the grabber outputs and what the encoder
accepts.<br>
Here down a verbose description.<br>
<br>
<br>
Regards,<br>
<br>
Renato<br>
<br>
A)<br>
<br>
I'll try to describe some basics about a video stream chain,
although it's very easy to find information on the Internet.<br>
Usually the chain is made of:<br>
1) a grabber, which gives complete frames in some FOURCC format
(RGB, YUV422, YUV420, ...);<br>
2) an encoder, which, in a run, accepts one of the FOURCC formats
and deflates the frames (in this case MF encoder);<br>
3) a streamer, which sends data to a receiver (in this case
Live555);<br>
4) a stream receiver, which receives data (in this case Live555
embedded in VLC);<br>
5) a decoder, which inflates data (in this case FFMPEG embedded in
VLC) and gives frames in the same FOURCC format as points 2;<br>
6) a renderer, which outputs the images on a video card (in this
case an output class embedded in VLC (e.g. on Windows a DirectX
surface for the same FOURCC format as point 5));<br>
<br>
Sometimes, but it's a bad performing design (heavy CPU load) the
chain also has any one or both of the following points:<br>
1-bis) a FOURCC format converter to adapt the grabber output to the
encoder input;<br>
5-bis) a FOURCC format converter to adapt the decoder output to the
renderer input.<br>
<br>
B)<br>
Now, if you are right when you say that your grabber outputs NV12
format frames (point 1), please check if your encoder accepts this
format or if it waits for YUV422 (point 2). If the format does not
match, a solution is implementing the point 1-bis; but it's better
to change the grabber output or the encoder input configuration (or
the encoder at all).<br>
<br>
C)<br>
Another check is to verify that the decoder output (point 5) matches
the encoder input (point 2), regardless the FOURCC format of the
data you feed in the encoder. Since you use VLC, please read its
documentation to know how to save each decoded frame.<br>
<br>
D)<br>
Another check is to verify that the receiver output (point 4)
matches the streamer input (point 4), using operRTSP at the receiver
side (not VLC).<br>
<br>
<br>
<br>
Il 04/01/2013 21.08, <a class="moz-txt-link-abbreviated" href="mailto:temp2010@forren.org">temp2010@forren.org</a> ha scritto:<br>
<blockquote
cite="mid:CAK0dNZim+t-RLOfo9ACR=KFwQhb6f7q_o0EvcpNMdKn5zHxQTA@mail.gmail.com"
type="cite">Renato,
<div><br>
</div>
<div>How would one go about rendering the stream for only the
luminance plane? Do you mean going into my MF H.264 encoder?
You must. Otherwise I don't know how to analyze the compressed
output to omit the color. And for the MF H.264 encoder, I don't
think there's any way to tell it to do only Y. Is this what you
were suggesting? If so, then how would one get around the
problem I just indicated? If not, what did you really mean.</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Fri, Jan 4, 2013 at 8:47 AM, Renato
MAURO (Libero) <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:renatomauro@libero.it" target="_blank">renatomauro@libero.it</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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 moz-do-not-send="true"
href="http://www.fourcc.org/yuv.php#NV12"
target="_blank">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>Il 04/01/2013 13.49, <a moz-do-not-send="true"
href="mailto:temp2010@forren.org" target="_blank">temp2010@forren.org</a>
ha scritto:<br>
</div>
<blockquote type="cite">
<div>
<div class="h5">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></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
live-devel mailing list
<a moz-do-not-send="true" href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a>
<a moz-do-not-send="true" href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a moz-do-not-send="true"
href="http://lists.live555.com/mailman/listinfo/live-devel"
target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br>
</blockquote>
</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>