Each valid RTP packet received for a specific service is inserted into the buffer if there is no existing RTP packet that matches the sequence number. When sequence numbers and timestamps discontinue, the video ISA makes a limited attempt to validate the MPEG stream. The video ISA code adopts a philosophy to ensure that sequence numbers and timestamps increment correctly. If packets are non-contiguous, the packet selection algorithm adapts.
Duplicate packets are detected by sequence number or timestamp, unless M-bit resets the timestamp. A packet that is already in the buffer and which has the same sequence number as a received packet (or one recently played out) is discarded. The system monitors the incoming sequence number on each RTP packet. If a packet takes more than 1.5 seconds, it is considered late and is discarded.
In a multiprogram transport stream (MPTS), the timestamp is uniquely set for every RTP packet, as any RTP packet many contain a number of multiplexed elementary streams. As a result, playout is based on the embedded timestamp in each RTP packet. In a single-program transport stream the inverse occurs. Many RTP packets can share the same timestamp as it is referenced from the start of a picture (and a picture can span many RTP packets). As an SPTS does not contain audio, its application is limited to content production and so only MPTS are supported.
Timestamp discontinuities do occur and are normally represented with the Marker bit (M) being set.
Playout time is determined by an internal playout timestamp. The playout timestamp is set independently from the actual timestamp in the packet. The recovered clock can compute the expected timestamp for the very next incoming RTP packet.
When a packet is received, it is first compared to existing packets in the buffer based on sequence number (assuming that a stream may be delayed for hundreds of milliseconds by a backup path yet still be valid); jitter tolerance is only evaluated if this packet is determined to be a new RTP packet eligible for buffer insertion. If jitter tolerance is exceeded, then a timestamp discontinuity is assumed and instead of setting the playout timestamp based on the contained RTP timestamp, the actual received time (offset by playout-buffer) is set for the RTP packet playout timestamp.
In normal operation, the clock is recovered from the timestamp field in the RTP header, is offset by the playout buffer configuration parameter, and is used to schedule playout of the packet. The playout clock is synchronized with the sender by using an adaptive clock recovery algorithm to correct for wander.
Algorithm summary
For a service marked LoT, if a loss of transport occurred, purge the buffer and reset all counters/timers.
If the service is UP, check the RTP packet sequence number. Compare to sequence numbers contained in the buffer. If no match then check last played sequence number. If the sequence number of this packet is between last played and last played + 4096 then consider this packet late and discard.
Check the expected timestamp recovered clock value and compare to RTP timestamp. If the expected timestamp is (-ve)jitter tolerance<timestamp<(+ve)jitter tolerance then the packet is admitted to the buffer with a playout timestamp per the embedded RTP timestamp. If jitter tolerance is not maintained this marks a discontinuity event. Set playout timestamp to current clock + playout buffer and enqueue.