So my question: is the rtpSource->curPacketRTPTimestamp() always
supposed to be larger than rtpInfo.timestamp?
No, RTP timestamps can wrap around (because they are 32-bit numbers).
In MediaSubsession::getNormalPlayTime(...), when rtpInfo.infoIsNew,
an offset is set as such:
u_int32_t timestampOffset =
rtpSource()->curPacketRTPTimestamp() - rtpInfo.timestamp;
This is correct. If "rtpSource()->curPacketRTPTimestamp()" happens
to be smaller than "rtpInfo.timestamp" (because the RTP timestamp has
wrapped around), then the actual offset should be
(2^32 + rtpSource()->curPacketRTPTimestamp()) - rtpInfo.timestamp
but this is just the same as
rtpSource()->curPacketRTPTimestamp() - rtpInfo.timestamp
if expressed as a 32-bit unsigned number.
Therefore the current code is correct, I believe.
(This assumes, however, that the RTP timestamp wraps around *at most
once* before the first RTCP "SR" packet is received (so that we can
compute a properly-synchronized presentation time). If your RTP
timestamp wraps around more than once, then that suggests that either
your server's RTCP rate is too low, or else your client is not
receiving RTCP at all.)
--
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
