> 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
