Transmit absolute time

[Tim Müller]

On Wed, 2015-10-21 at 16:15 +0200, Pietro Bonfa' wrote:

> the PTS of the incoming buffers in rtpatimetimestamp (*) starts from
> 3600000000000000 (ns) independently on the PTS information present in
> the source element.
> I'm tend to think that this is due to x264enc but I cannot find
> anything
> about this in the docs.

This is something that was done/added/changed in 1.6, in order to
accommodate negative DTS timestamps. Timestamps in GStreamer are
defined as unsigned, and that couldn't easily be changed, but it was
easily possible to shift the timeline and then configure the segment to
be such that running time still ends up same as before, which is what's
done here.

If you compare with e.g.:

$ gst-launch-1.0 videotestsrc ! x264enc ! fakesink silent=false -v |
grep chain | head -n 10
6470 bytes, dts:  999:59:59.933333334, pts: 1000:00:00.000000000
4121 bytes, dts:  999:59:59.966666667, pts: 1000:00:00.133333333
4244 bytes, dts: 1000:00:00.000000000, pts: 1000:00:00.066666666
4042 bytes, dts: 1000:00:00.033333333, pts: 1000:00:00.033333333

you can see how the DTS of the first two buffers would've been negative
if pts started at a 0 value, and that wasn't possible.

The shift amount was chosen such that it was easy to see in the debug
log what the timestamps were before being shifted.

Cheers
 -Tim

-- 
Tim Müller, Centricular Ltd - http://www.centricular.com