<div dir="ltr">Hi Mike,<div><br></div><div> This might be helpful <a href="https://bugzilla.gnome.org/show_bug.cgi?id=762326">https://bugzilla.gnome.org/show_bug.cgi?id=762326</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 March 2016 at 11:07, Mike Stirling <span dir="ltr"><<a href="mailto:gstreamer@mikestirling.co.uk" target="_blank">gstreamer@mikestirling.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I am attempting to derive wall-clock timestamps from the buffers obtained from an off-brand IP camera's RTP stream.  The camera itself does not appear to support RTCP sender reports (as observed with Wireshark), so I have assembled a pipeline that uses an explicit GST_CLOCK_TYPE_REALTIME clock.  The pipeline has the following elements:<br>
<br>
rtspsrc->rtph264depay->h264parse->queue->appsink<br>
<br>
I can obtain wall-clock time in my appsink by taking the buffer pts + gst_element_get_base_time(element) - this works as expected.<br>
<br>
The problem arises if I temporarily break the stream (pull the network cable) for a few seconds (not long enough to cause the connection to drop).  When the stream comes back up the buffer PTS values seem to restart from 0, which causes the calculated wall-clock time to jump backwards.  I was expecting to see a new-segment event on the appsink's sink pad, containing the new start offset, but this doesn't arrive.<br>
<br>
What am I missing?<br>
<br>
Gstreamer version is 1.6.1 (from source).<br>
<br>
Regards<br>
Mike<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>