Unexpected buffer timestamps after x264enc

[David Jaggard]

Thank you Nicolas. My issue was I had not taken into consideration the
segment event. Thank you to Sebastian for pointing me to the segment
running time function.

I used a pad probe on my sink to capture the segment event and now when I
apply the segment information and the sink latency to the buffer timestamp
I can see that it does (within milliseconds) match the clock time.

On 7 December 2015 at 14:44, Nicolas Dufresne <
nicolas.dufresne at collabora.com> wrote:

> Le dimanche 06 décembre 2015 à 11:17 +0000, David Jaggard a écrit :
> > The timestamp of the first buffer to enter the x264enc is 5182ms. The
> > timestamp of the first buffer to leave is 3600000000ms. Subsequent
> > buffers increase monotonically from there. Given the clock time at
> > this point was around 6400ms how does the sink (multiudpsink in this
> > case) know when to 'display' this?
> >
> > Incidentally the latency at the sink was 1220ms and post buffer
> > timestamp - 3600000000ms + 5182ms + 1220ms = ~6400ms (the clock
> > time).
>
> Timestamp are not measure of clock time. x264enc push forward the
> timestamp to avoid negative values. These values are pushed forward in
> a way that they are readable when printed with GST_FORMAT_TIME macros.
>
> The sink will convert those timestamp to running time (and then to
> clock time) in order to compare information that do correlate.
>
> Nicolas
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151207/3a57ea13/attachment.html>