> On Jul 29, 2021, at 1:57 AM, DJM-Avalesta <david.my...@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/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
