[Live-devel] RTP presentation times

Ross Finlayson finlayson at live555.com
Thu Jul 29 05:09:37 PDT 2021



> On Jul 29, 2021, at 1:57 AM, DJM-Avalesta <david.myers at avalesta.com> wrote:
> 
> I could replace gettimeofday with something like this, but is this valid?
>   if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0) 
>     gettimeofday(&fPresentationTime, NULL);
>   else 
>   	{
>     // Increment by the sample time
>     unsigned uSeconds = fPresentationTime.tv_usec + 1000000/25; //25fps, the frame rate
>     fPresentationTime.tv_sec += uSeconds/1000000;
>     fPresentationTime.tv_usec = uSeconds%1000000;
>   }

Yes, this should work fine.  (Note that this is basically what we already do in the implementation of the “H264or5VideoStreamFramer” class, which we use for streaming H.264 or H.265 video byte streams.)

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()”.)


> Also, other encoders seem to have the same timestamp for the SPS and PPS frames as for the corresponding video frames, whereas my encoder has individual timestamps on the SPS and PPS packets, which are different from the video frames timestamps.
>  
> 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.


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




More information about the live-devel mailing list