[Live-devel] How to limit the number of RTP packet which is received from MultiFramedRTPSource?

[Ross Finlayson]

The “ReorderingPacketBuffer” is used to temporarily hold incoming packets whenever a ‘gap’ in the RTP sequence number is detected.  Such a gap can have two possible causes: (1) an incoming packet was lost, or (2) an incoming packet was delayed (i.e, reordered in the network), and will arrive later.  To distinguish between these two cases, we wait for a short period of time (the ‘packet reordering threshold time’).  If the ‘missing’ packet arrives within this time, then it will be delivered (in order).  Otherwise we assume that the packet was lost, and continue handling incoming packets.

The default value of the ‘packet reordering threshold time’ is 100000 microseconds - i.e., 100ms - but you can change it by calling “setPacketReorderingThresholdTime()” on the “RTPSource” object.

It’s important to understand (because many people seem to keep misunderstanding this) that the “ReorderingPacketBuffer” is used *only* when packet loss (or packet reordering) is detected, and never delays incoming packets more than the ‘packet reordering threshold time’.  If no incoming packets are lost (or reordered) in the network, then then the “ReorderingPacketBuffer” is not used, and introduces absolutely *no* latency.

But (once again), if you *really* want to reduce the number of packets that can get (temporarily) stored in the “ReorderingPacketBuffer” (again, this happens only when there are lost or reordered packets), you can do so by calling “setPacketReorderingThresholdTime()” with a number smaller than 100000 (microseconds).  Be warned, however, that if you set this too small, you’ll stop handling reordered packets; they’ll end up being treated as if they were lost.


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