Hi, Thanks for your answer. My RTP data is a compressed raw data. I can't use RaeVideoRTPSource because my frame length is dynamic. I don't think that I have another optional source to use. SimpleRTPSource could identify the drops using fHeadPacket->rtpSeqNo() > fNextExpectedSeqNo . I would except that MultiFramedRTPSource will drop all packets until next marker bit, but this is not the behavior. I'm getting the frame as valid frame even so the frame is short than expected? Would like to better understand current implementation. Thanks,CS
-----Original Message----- From: live-devel [mailto:live-devel-boun...@us.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, January 29, 2020 10:14 To: LIVE555 Streaming Media - development & use <live-de...@us.live555.com> Subject: Re: [Live-devel] Frame dropping on case of packet loss > On Jan 28, 2020, at 10:47 PM, Spungin, Chaya <chaya.spun...@intel.com> wrote: > > > Hi, > I’m using SimpleRTPSource and see some corrupted messages when the data > arrives. > I saw that the corrupted messages are a result of some packets drop. > I would expect that after any packet drop the whole frame will be > dropped, but this is not the situation, The MultiFramedRTPSource continue to > build the frame and pass it upstream. > I would like to understand the expected behavior on such case. The first question to ask is - Why are you using “SimpleRTPSource”? What kind of RTP data is this? (i.e., What is the codec?) Perhaps some other “RTPSource” subclass would be more appropriate for this kind of data? The issue you are running into is (probably) that incoming frames are too big to fit into a single RTP packet, so they get fragmented into multiple RTP packets. And some of these RTP packets are getting lost. Usually, video RTP payload formats use the RTP “M” (‘marker’) bit to signal the last packet of the frame. Our implementation of “SimpleRTPSource” (via the parameter “doNormalMBitRule”; default value True) uses this to help figure out when a frame has *ended*. But it can’t know when a frame has *started*. So it’s not perfect in figuring out whether or not a frame is complete. But RTP payload formats (for particular codecs) usually have their own way of tagging whether or not a RTP packet begins a frame. So we come back to the first question: What kind of data is this? Perhaps some other “RTPSource” subclass would be more appropriate? 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 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
