Hi! Thanks for the answer.
"*any* of these packets gets lost," Some questions: Does it mean that RPT protocol is unreliable? So, if 'slices' (NAL units) would be delivered through RPT, can they be lost too? Why the 'slices' way is more reliable? Is a unreliable transmission normal (reality)? In what object I must realize 'slices' technology? Nick From: live-devel-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, October 15, 2013 8:59 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] DeviceSource Translate large frames (fNumTruncatedBytes) I try translate H264 video stream by Live555. The hardware video source is the video camera (USB). Class for Live555 video source derived from DeviceSource. The problem in function DeviceSource::deliverFrame : When the newFrameSize > <http://www.live555.com/liveMedia/doxygen/html/classFramedSource.html#7f4137 643c61539e313e3a92085efc08> fMaxSize i set <http://www.live555.com/liveMedia/doxygen/html/classFramedSource.html#337ad4 9493202c89afd93564cc6263da> fNumTruncatedBytes, but only result is the message: "The input frame data was too large for our buffer size :.. bytes of trailing data was dropped!" This mean (as I understand) that the truncated part of frame is dropped. Is this mean that the truncated frame is dropped? Yes. If the input frame is larger than the buffer space that the downstream object provides, then you will *not* be able to deliver all of the data. The remaining data will be truncated (i.e., dropped, lost). In message we have recommendation: "Correct this by increasing \"OutPacketBuffer::maxSize\" to at least" Is any way to sending large frames (H264 key frames , or other), except the HUGE fMaxSize? No. The downstream object's buffer must be large enough to receive the frame. However, this shows why very large H.264 key frames are a bad idea. Even if you have a large enough buffer to stream these frames, each one will be packed into many outgoing RTP packets. If *any* of these packets gets lost, the receiver will be unable to reconstruct the frame. Instead, it is much better if you can break up each 'key frame' into several 'slices' (each of which would be its own H.264 NAL unit). Each of these slices (NAL units) would be delivered separately. Ross Finlayson Live Networks, Inc. http://www.live555.com/ __________ Information from ESET NOD32 Antivirus, version of virus signature database 8913 (20131014) __________ The message was checked by ESET NOD32 Antivirus. ????????? ??????????? ????? - - O? ????????? ??????????? ????? - - O? ???????? ??? ????? 00026.txt - - O? http://www.esetnod32.ru/.ml
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
