Unexpected buffer timestamps after x264enc

[Nicolas Dufresne]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151207/4ddf6636/attachment.sig>