>Do you mean going into my MF H.264 encoder? You must.
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).
So, I mean to memset to 0x80 all the U and V bytes of the grabber output
(see http://www.vidcheck.com/whitepapers.asp to know why 0x80 and not
0x00, which would give the default green color).
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.
Here down a verbose description.
Regards,
Renato
A)
I'll try to describe some basics about a video stream chain, although
it's very easy to find information on the Internet.
Usually the chain is made of:
1) a grabber, which gives complete frames in some FOURCC format (RGB,
YUV422, YUV420, ...);
2) an encoder, which, in a run, accepts one of the FOURCC formats and
deflates the frames (in this case MF encoder);
3) a streamer, which sends data to a receiver (in this case Live555);
4) a stream receiver, which receives data (in this case Live555 embedded
in VLC);
5) a decoder, which inflates data (in this case FFMPEG embedded in VLC)
and gives frames in the same FOURCC format as points 2;
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));
Sometimes, but it's a bad performing design (heavy CPU load) the chain
also has any one or both of the following points:
1-bis) a FOURCC format converter to adapt the grabber output to the
encoder input;
5-bis) a FOURCC format converter to adapt the decoder output to the
renderer input.
B)
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).
C)
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.
D)
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).
Il 04/01/2013 21.08, [email protected] ha scritto:
Renato,
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.
On Fri, Jan 4, 2013 at 8:47 AM, Renato MAURO (Libero)
<[email protected] <mailto:[email protected]>> wrote:
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 http://www.fourcc.org/yuv.php#NV12.
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.
So: 640 x 480 x 1,5 = 450 kBi = 3.51 Mbi uncompressed => 3.51 Mbi
/ 160 kbi = 22,5 times.
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.
Regards,
Renato
Il 04/01/2013 13.49, [email protected]
<mailto:[email protected]> ha scritto:
Thanks very much for your help, Ross.
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().
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?
Thanks again.
_______________________________________________
live-devel mailing list
[email protected] <mailto:[email protected]>
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
[email protected] <mailto:[email protected]>
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
