[Live-devel] RTP presentation times

[Ross Finlayson]

> On Jul 29, 2021, at 7:21 AM, DJM-Avalesta <david.myers at avalesta.com> wrote:
> 
> Many thanks for the response, Ross.
> 
> You wrote
> >> The only important thing to note here is that the “fPresentationTime”s need to correspond to the times that you’d get by calling 
> >> “gettimeofday()” - i.e., you can’t use your own clock with completely different values to set the “fPresentationTime”s.  
> >> (The reason for this is that our code - when computing ‘wall clock’ times for outgoing RTCP “SR” packets - uses “gettimeofday()”.)
> 
> Just to clarify, by "needs to correspond", do you mean the format of the time within fPresentationTime here? So as long as I call gettimeofday once at the start of the stream and increment it as a struct timeval, as shown below, am I ok?

All I meant was that you can’t use your own clock that starts with with a completely different value than what “gettimeofday()” would give you.  E.g., your “fPresentationTime”s couldn’t start with 0.  But calling “gettimeofday()” just once at the beginning, and then just incrementing the “fPresentationTime”s based on the frame rate - as you propose, and which we already do in “ H264or5VideoStreamFramer" - is OK.


> You also wrote
> 
> > Do I need to add logic to give SPS and PPS frames the same timestamp as the corresponding video frames?
> 
> >>  I’m not sure how important this is; it depends on whether or not decoders care about this.
> 
> On an i-frame my StreamSource::deliverFrame() function gets called 3 times, ie for the SPS frame, the PPS frame and for the video data. I could advance the presentation time for the SPS frame and not for the PPS and video, as long as I can count on the frames always being in this order. On a p-frame, I just need to advance the presentation time.
> 
> This seems very complicated compared to just calling gettimeofday() every frame, am I missing something here?

Once again, I have no idea how important the presentation times for SPS and PPS NAL units are to decoders.  That’s something that you’ll need to figure out for yourself, based on whatever decoder(s) your receivers end up using.  So, this is not really a ‘LIVE555’ question.


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