[Live-devel] Starting Frames are corrupted

[Vikram Singh]

Hi ross,

 

I am having --  unsigned OutPacketBuffer::maxSize = 900000;  in
mediaSink.cpp

If I decrease the maxSize then the frames I get are truncated.

 

Can you please specify how to decrease the nal unit size without decreasing
the value of maxSize.

 

Thanks 

Vikram Singh

 

From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of
Ross Finlayson
Sent: Wednesday, June 18, 2014 7:03 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Starting Frames are corrupted

 

I am testing the testH264VideoStreamer.cpp provided in the testprogs of
live555 library folder.
This file will stream a h264 file.
My h264 file is not corrupted.
I am viewing the stream using vlc player.

 

(Sorry, I sent my previous email before I read your last email, in which you
explained what you're doing.)

 

Your problem is that your stream contains extremely large 'I- frames' (also
known as 'key frames'), and your encoder is encoding each I-frame so that it
takes up a single H.264 NAL unit.

 

If you're using VLC as a client, then be aware that - if your I-frame NAL
units are excessively large - the first few received frames *will* be
truncated.  VLC notices this and increases its buffer size, so after a few
seconds should have increased its buffer size large enough.  That's why you
see video corruption only for the first few frames.  (There may be an option
in VLC to use a larger initial buffer size.  However, VLC is not our
software, so we can't help you with VLC-related problems.)

 

It's important to understand that each outgoing NAL unit - if it is larger
than the RTP/UDP packet size (about 1500 bytes on most networks) - will be
broken up into multiple outgoing RTP packets, and the receiver must receive
*all* of these packets in order to be able to reconstruct the frame.  In
other words, if even one of these packets is lost, then the receiver will
lose the *entire* NAL unit.  That's why the NAL units - generated by your
encoder - should be as small as is reasonable.

 

The best solution here - for streaming - is to to not send extremely large
NAL units.  I-frames should be encoded as multiple 'slice' NAL units.
Reconfigure your encoder to break up 'key frames' into multiple (therefore
much smaller) 'slice' NAL units.

 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140618/ebd4127a/attachment-0001.html>