GNOME Bugzilla – Bug 701353
rtp timestamps not correct when pausing/seeking
Last modified: 2018-05-06 12:36:08 UTC
rtp should have timestamps that are monotonically increasing and should not stop due to pause or reset due to seek. The functionality today is based on running time which works until pausing (running time will halt) or seeking (running time will be 0 again).
Created attachment 245728 [details] [review] Patch Take the base time of the element when going to playing the first time after being in ready. Instead of using running time directly, we subract the element base time (to get clock time) and subtract this initial base time to get a time that doesn't pause or reset at flushing seek and starts at 0.
Created attachment 245731 [details] [review] Patch # 2 same as before, just removed some ws changes
Review of attachment 245731 [details] [review]: ::: gst-libs/gst/rtp/gstrtpbasepayload.c @@ +858,3 @@ + rtime += gst_element_get_base_time (GST_ELEMENT (payload)); + /* remove initial base time to get a time line starting from 0 */ + rtime -= payload->priv->initial_element_base; What happnens if you preroll a buffer in PAUSED ? (where priv->initial_element_base == GST_CLOCK_TIME_NONE) Might make sense to use "0" instead of as a "unset" value ?
Created attachment 245894 [details] [review] Patch 3 Force rtime to 0 if we are prerolling
(In reply to comment #3) > Review of attachment 245731 [details] [review]: > > ::: gst-libs/gst/rtp/gstrtpbasepayload.c > @@ +858,3 @@ > + rtime += gst_element_get_base_time (GST_ELEMENT (payload)); > + /* remove initial base time to get a time line starting from 0 */ > + rtime -= payload->priv->initial_element_base; > > What happnens if you preroll a buffer in PAUSED ? (where > priv->initial_element_base == GST_CLOCK_TIME_NONE) > > Might make sense to use "0" instead of as a "unset" value ? You are correct, but we can't just use 0 since that would mean the first package would have rtime same as clock time and the rest starting from 0. I made a special case for this instead.
You can't do this, the element is already processing rtp packets while it goes from paused to playing and you will end up with some timestamp with and some without the base-time. You would have to make the element a live element or no-preroll to make it use the pipeline clock to adjust the rtp time. It should probably be done in the session manager so that it can also keep the SR packets consistent with the modified RTP timestamps.
I understand. Guess it's back to the drawing board :P
(In reply to comment #7) > I understand. Guess it's back to the drawing board :P It's not only that the clock isn't available in PAUSE either if I'm right... Lets take this (very much made up) example: filesrc -> payloader -> queue -> networksink here we could get all the content through the payloader before going to play, causing pauses having no effect at all on the rtp timestamps as they should. It seems to me that the one making the rtp timestamping by necessity needs to be synchronized to the clock, otherwise we won't be able to react synchronized to the incoming pause/play commands. I am not sure how the session manager would help? Could you be more specific about that?
What's the status here?
The status is that Alexander has left Axis Communications. I have tried to subscribe to all his still opened bugs, like this one, to keep track of what was happening just before he left. I'm trying to drive these things with my project manager, but so far other things have had higher prio. I still aim to do something about this, so please keep this ticket open.
Sebras, is this still a problem with current versions, and is this still on your list?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!