[Live-devel] How to release frame; How to improve horrible video quality
Renato MAURO (Libero)
renatomauro at libero.it
Sat Jan 5 04:56:00 PST 2013
>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, temp2010 at forren.org 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)
> <renatomauro at libero.it <mailto:renatomauro at libero.it>> 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, temp2010 at forren.org
> <mailto:temp2010 at forren.org> 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
>> live-devel at lists.live555.com <mailto:live-devel at lists.live555.com>
>> http://lists.live555.com/mailman/listinfo/live-devel
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com <mailto:live-devel at lists.live555.com>
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130105/3a18f7ff/attachment-0001.html>
More information about the live-devel
mailing list