What you’re still not apparently understanding here is that RTP timestamps are
used only as a shortcut to transfer the presentation time from the sender to
the receiver. I.e.
(sender) presentation time -> RTP timestamp in RTP packets ->
presentation time (receiver)
In other words, the presentation time is *all* that you have. Seeing the RTP
timestamp as well would give you ***no more information*** (because the RTP
timestamp is used only to compute the presentation time, and the resolution of
the presentation time is the same as that of the RTP timestamp).
In other words, the *only* ’time' information that you have about each incoming
frame is the presentation time.
If, for whatever reason, the presentation time (as generated by the sender, and
received by the receiver) does not advance sufficiently smoothly for your
taste, then that’s a problem for you (the receiver) to deal with. You don’t
know for sure why the sender might be behaving this way (remember that a proper
RTP receiver needs to be able to work with *any* compliant RTP sender, not just
the server that you’re using right now) - but simply ignoring the effect of the
sender’s RTCP “Sender Reports” (which is what you’d effectively be doing if you
were to ignore the computed presentation times and look only at the RTP
timestamps) is never the right thing to be doing. It is precisely these
presentation times that tell you when to ‘present’ each frame of media, and
also let you synchronize separate audio and video streams (if you have them).
And if, for whatever reason, your RTP sender (server) is not compliant, then
you'll need to fix it.
> Would you kindly reconsider exposing the RTP timestamp in RTPSource?
No, for the reason that I stated.
(This will be my (and your) last posting on this topic.)
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
