[Live-devel] Starting Frames are corrupted

[Jeff Shanab]

A related technical question. Can we split a large Iframe nal frame into
slices after the fact? Sometimes the encoder is a closed piece of
hardware/firmware. Is it possible to split it into slices at a macroblock
boundary?


On Wed, Jun 18, 2014 at 10:19 AM, Vikram Singh <vikram at vizexperts.com>
wrote:

> 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/
>
>
>
> _______________________________________________
> 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/20140618/0e4b19d0/attachment-0001.html>