Ross, Thanks for the answer. That clarifies things. Another question. You say:
If, however, the 'packet reordering threshold' threshold elapses without packet N+1 arriving, then (the already-arrived) packet N+2 will get delivered instead. In this case, packet N+1 will never get delivered, even if it happens to arrive later. But suppose that the next packet is not N+2 but N+3? What happens in this case? Is there another delay of 100ms? Or the most delay is 100ms and whatever packet arrives next is delivered? In other words, suppose only N+2 is delayed we would have: N, N+1, ---delay 100ms --- N+2 But suppose N+2 and N+3 are delayed would we have? (Assuming that the threshold is expired) N, N+1, ---delay 100ms --- N+4 Or N, N+1, ---delay 100ms---, ---delay 100ms---, N+4 Thanks, -Zahira -Zahira From: live-devel-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, September 05, 2013 5:45 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Packets and delay Can you please explain what happens when a packet is being delayed? I seem to understand that each packet has a life time and it gets discarded when its time is up. Does lives555 wait for the following packets to arrive, or does it continue delivering packets to client and then deliver the previous packets (out of order?). Our "RTPSource" class (and subclasses) *always* delivers (the payload of) incoming RTP packets in order. In other words, data is *never* delivered out-of-order, even if incoming RTP packets happen to be misordered. If there is no packet loss - or misordering - in the network, then our code always delivers (the payload of) incoming RTP packets without delay. I.e., if the last-received RTP packet had RTP sequence number N, and the next incoming packet has RTP sequence number N+1 (mod 65536), then this next incoming packet is always delivered immediately. If, however, the next incoming packet has RTP sequence number N+2 (or later), then its payload is not delivered immediately. Instead, it is delayed by the 'packet reordering threshold', to see what subsequent packets happen to arrive. If packet N+1 arrives before the 'packet reordering threshold' time, then it will then get delivered, followed by (the already-arrived) packet N+2. If, however, the 'packet reordering threshold' threshold elapses without packet N+1 arriving, then (the already-arrived) packet N+2 will get delivered instead. In this case, packet N+1 will never get delivered, even if it happens to arrive later. By default, the 'packet reordering threshold' is 100 ms. Therefore, incoming packets may be delayed by this time - but *only* if there is packet loss in the network. It's important to understand that this is the *only* place in our code where incoming packets may be delayed before being delivered. If you are seeing delays greater than 100ms, then it is *not* happening in our code, so don't waste your time looking for it there. 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
