[Live-devel] Frame dropping on case of packet loss

[Spungin, Chaya]

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-bounces at us.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, January 29, 2020 10:14
To: LIVE555 Streaming Media - development & use <live-devel at 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.spungin at 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 at 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.