Appsink RTP timestamps return to 0 after stream discontinuity

[Serj TorresSoldado]

Hi Mike,

 This might be helpful https://bugzilla.gnome.org/show_bug.cgi?id=762326


On 31 March 2016 at 11:07, Mike Stirling <gstreamer at mikestirling.co.uk>
wrote:

> Hi all,
>
> 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:
>
> rtspsrc->rtph264depay->h264parse->queue->appsink
>
> I can obtain wall-clock time in my appsink by taking the buffer pts +
> gst_element_get_base_time(element) - this works as expected.
>
> 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.
>
> What am I missing?
>
> Gstreamer version is 1.6.1 (from source).
>
> Regards
> Mike
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160405/fb9b7a21/attachment.html>