[Live-devel] Delay problem of the first RTCP "SR" packet

[Ross Finlayson]

First, note that developers (using the LIVE555 libraries) never need to concern themselves with RTP timestamps.  Our library automatically converts presentation times to RTP timestamps (when sending), and from RTP timestamps to presentation times (when receiving).  See http://live555.com/liveMedia/faq.html#why-are-rtp-timestamps-not-visible


> 2) Does PTS at client always monotonically increase even in case RTPTimestamp (32-bit) is wrapped around?.

The computation of presentation times automatically take account of RTP timestamps wrapping around.

However, presentation times are not necessarily monotonically increasing, because - in RTP - video frames are sent (and received) in ‘decoding order’ (i.e., the order which frames would be fed into a decoder), not ‘display order’.  If a video stream contains ‘B frames’ (this is MPEG-4 terminology; I don’t know what the corresponding term is in H.264/5) whose decoding depends upon a later frame, then the later frame will be sent (and received) before the ‘B frames’.


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