Transmit absolute time

[Pietro Bonfa']

On 10/21/2015 04:26 PM, Sebastian Dröge wrote:
> However
> the timestamps (PTS) are not the interesting things. The corresponding
> clock-time is.

Ok, so if I cannot trust PTS think I'm lost again.

If by "clock-time" you mean gst_segment_to_running_time or
gst_segment_to_stream_time this is not sufficiently accurate (see code
attached).

Considering this pipeline

"appsrc name=mysrc ! autovideoconvert ! x264enc tune=\"zerolatency\" !
appsink name=mysink"

I provide a piece of output

SRC: function begins, time is: 7920116ms (2:12:00.116802521)
SRC: PTS: 1500000000 BASETIME 7919124068290 SUM 7920624068290
SRC: function ends, time is: 7920116ms (2:12:00.116879766)


SINK: PTS: 3600001000000000
SINK: PTS + begin : 3607919616792629 (1002:11:59.616792629)
SINK: gst_segment_to_stream_time: 1000
SINK: gst_segment_to_stream_time + base_time: 7920124068290
(2:12:00.124068290)

SINK: PTS: 3600001500000000
SINK: PTS + begin : 3607920116792629 (1002:12:00.116792629)
SINK: gst_segment_to_stream_time: 1500
SINK: gst_segment_to_stream_time + base_time: 7920624068290
(2:12:00.624068290)


As you can see PTS + begin (begin is my own field where I save the time
when the first frame was produced) corresponds to when the function is
called (1002:12:00.116792629 vs 2:12:00.116802521) while instead
gst_segment_to_stream_time + base_time is off by about 8 ms if I
consider the encoded frame with PTS 3600001000000000.

Do I have alternatives to gst_segment_to_stream_time or
gst_segment_to_running_time?
My only idea now is to switch to metadata also in the source and parse
timestamps from metadata.

Thanks,
Pietro



-------------- next part --------------
A non-text attachment was scrubbed...
Name: test7.c
Type: text/x-csrc
Size: 5517 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151022/bce1e51a/attachment-0001.c>