[Live-devel] problems with packet loss

[Ross Finlayson]

>Hello!
>
>I am streaming H263plus and I have have two question concerning packet loss.
>
>At the receiving site at MediaSink

???  RTP receivers use a MediaSource (subclass).  RTP senders use a 
MediaSink (subclass)

>, doing:
>
>rtp_source = dynamic_cast<RTPSource*>(fSource);
>rtp_source->curPacketRTPSeqNum()
>
>it seems that some packets get lost. There are always 12 packets
>arriving correctly and then 7 packets are lost.
>
>However, RTPTransmissionStats::totNumPacketsLost() tells me, that no
>packets are lost.

"RTPTransmissionStats" is used only by senders ("RTPSink"s).  At the 
receiving end ("RTPSource"s), you should look at "RTPReceptionStats".

>
>Am I misinterpreting curPacketRTPSeqNum() ?

Possibly.  Remember that more than one incoming RTP packet can make 
up a complete video frame, but that "curPacketRTPSeqNum()" returns 
only the sequence number of the *last-received* RTP packet.  (This is 
why "curPacketRTPSeqNum()" should not really be exposed as a public 
member function in the API; sometime in the future, it will likely be 
removed.)

>Secondly, if I have bad network conditions (now even
>RTPTransmissionStats::totNumPacketsLost()) tells me, that packets get
>lost) I have the following problem:
>
>If I look at "presentationTime" at the receiver, the time difference
>between two arriving packets is always the same, even if packets in
>between got lost. E.g. if packets No.1 and 2 arrive in a row, then the
>time difference is x. But if packets No.1 and  No.3  arrive  in  row
>because No.2 got lost, then their  time difference is also  x (although
>it should be 2*x)  How does that come?

I don't know, but perhaps you are not setting correct presentation 
times in your sender??

>
>One last general question: With H263plus, can I assume that one
>RTP-Frame always contains one Video-Frame?

No.  Large frames may be fragmented over several RTP packets. (See above.)

Note also that packet loss can be caused by insufficiently large 
socket reception buffers in the receiver's OS.  See 
<http://lists.live555.com/pipermail/live-devel/2007-May/006798.html> 
for a tip on how you may be able to overcome this.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/