> 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@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
