GNOME Bugzilla – Bug 762326
gstrtpjitterbuffer GST_QUERY_POSITION reports position and not stream_time
Last modified: 2018-11-03 15:07:54 UTC
rtpjitterbuffer reports the segment position instead of stream time for a position query. in pop_and_push_next() we see that: 1) pts is set with gst_segment_to_position() 2) last_out_time is set with the pts 3) gst_rtp_jitter_buffer_src_query responds to a GST_QUERY_POSITION using npt_start and last_out_time.
Created attachment 321664 [details] [review] Generating segment event with ntp time from RTCP Added a variable in gstrtpjitterbuffer to store the stream_time. Added a boolean property in gstrtpbin to generate segment events with the ntp time. The gstrtpjitterbuffer then catches the segment.
The patch only works when creating a pipeline with a rtspsrc source and querying this element for the position. Querying any other element seems to return the segment position and not the stream time.
Review of attachment 321664 [details] [review]: ::: gst/rtpmanager/gstrtpjitterbuffer.c @@ +3809,2 @@ JBUF_LOCK (priv); + stream_time_ = priv->stream_time; I didn't review the other parts yet, but what you really want here is to return gst_segment_to_stream_time() with the last position. That should give you the same value unless the segment is wrong, in which case the segment must be fixed anyway.
That is what I am doing, by using a proxy variable priv->stream_time and setting it in pop_and_push_next() because it seems that gst_segment_to_stream_time's last parameter comes from a RTPJitterBufferItem. Thanks for the help
No I mean instead of adding a new variable, just pass the value we had previously there to gst_segment_to_stream_time() before putting it as a result into the position query.
Created attachment 321671 [details] [review] Generating segment event with ntp time from RTCP2 Doing gst_segment_to_stream_time() inside the query function. Not sure what impact keeping "start = priv->npt_start;" has, it seems to be always 0.
It's non-0 when using RTSP and having seeked to a non-0 position.
Review of attachment 321671 [details] [review]: ::: gst/rtpmanager/gstrtpbin.c @@ +1464,3 @@ + (G_GINT64_CONSTANT (1) << 32)); + /* convert from 1900 based time to 1970 based time */ + ntpnstime -= 2208988800000000000LL; Why do you do this conversion here? This seems to defeat the purpose a bit, you are going to report "time since 1970" as stream time instead of "time since 1900", the latter actually being the NTP time. @@ +1474,3 @@ + * time values and get the equivalent NTP time. + */ + segment->time = ntpnstime - local_running_time; This is unsigned, but ntpnstime can be smaller than the local running time. Not sure what to do about that. It should also be relative, i.e. segment->time += ...
Hi Sebastian, It seems that gstreamer uses the unix epoch format and I am doing the conversion to use it in the segment event. Regarding the edge cases, wouldn't that only happen if the reported ntp time was close to it's epoch (1900) and/or the local_running_time (which from what I understand starts from 0) is big.
GStreamer does not define any epoch for the times, why do you think it's the UNIX epoch? The running time can start from a high value too, e.g. if you manually set the base time of a pipeline to 0 it will start at the current clock time.
I got the wrong impression by reading get_current_times(). It there any way to change the clock's base timestamp? I am trying to use gst_segment_set_running_time() but to no avail..
What are you trying to do, what is the result you'd like to have? :) Just the NTP timestamp in a 64 bit integer returned from the POSITION query? If so, no adjustments have to be made and I think it would make sense like that. Question is just what to do if the subtraction there does not work because overflow.
The objective is the same as originally, to find an appropriate method to expose the ntp timestamps from the RTCP SR through gstreamer. From what I've understood it should be exposed through the stream_time which is what should be returned from using gst_element_query_position() although at least for rtspjitterbuffer gst_element_query_position() returns the actual stream position instead of the stream_time. Now there is the problem of representing the ntp offset because the running time value might be bigger than the ntp timestamp and therefore the difference cannot be represented in segment->time. We could always make time be a signed value.. but I don't know what issues might arise from that. Other issues might arise with stream operations (seek/trickmode?)..
Created attachment 321863 [details] [review] Same as before but doing nothing when overflow
You can get around this overflow though. Instead of moving the stream time, you could move the running time and then also offset the buffer timestamps. Not nice though :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/258.