> On Jul 29, 2021, at 7:21 AM, DJM-Avalesta <david.my...@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/


_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to