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 <[email protected]> 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:[email protected]] *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 > [email protected] > http://lists.live555.com/mailman/listinfo/live-devel > >
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
