Transmit absolute time

[Sebastian Dröge]

On Do, 2015-10-22 at 16:05 +0200, Pietro Bonfa' wrote:
> On 10/22/2015 12:45 PM, Sebastian Dröge wrote:
> > gst_segment_to_running_time() + gst_element_get_base_time() should
> > give
> > you the *accurate* clock time. If it doesn't, there is a problem
> > somewhere. It shouldn't be off by 8ms, maybe by ± 1ns due to
> > rounding.
> 
> 
> To me it looks like there are two problems (with respect to what I
> want to achieve).
> 
> The first one is probably related to my code. The definition of the
> base_time is delayed for some reason:
> 
> SRC: ctx begin set to: 17920098ms (4:58:40.098913868)
> SRC: function begins, time is: 17920098ms (4:58:40.098975747)
> SRC: PTS: 0 BASETIME 0 SUM 0
> SRC: function ends, time is: 17920099ms (4:58:40.099009970)
> 
> SRC: function begins, time is: 17920598ms (4:58:40.598982328)
> SRC: PTS: 500000000 BASETIME 0 SUM 500000000
> SRC: function ends, time is: 17920599ms (4:58:40.599086461)
> 
> SINK: PTS: 3600000000000000
> SINK: PTS + begin : 3617920098913868 (1004:58:40.098913868)
> SINK: gst_segment_to_stream_time: 0
> SINK: gst_segment_to_stream_time + base_time: 17920606831790
> (4:58:40.606831790)
> 
> SRC: function begins, time is: 17921098ms (4:58:41.098920114)
> SRC: PTS: 1000000000 BASETIME 17920606831790 SUM 17921606831790
> SRC: function ends, time is: 17921099ms (4:58:41.099005949)
> 
> I'm not sure that this is a real problem (output from
> gst_segment_to_running_time is correct indeed) but could be a hint of
> something wrong in my code.

That the base time is not known when the first buffer happens in the
source is indeed a problem. How are you generating buffers and when?
You should only do that once the pipeline is actually in PLAYING,
otherwise you can't know which timestamps to put on them anyway.

running_time + base_time should always be exactly the clock time when
the buffer was captured.

> The second problem, (totally unrelated with my code) is that
> gst_element_get_base_time() gives the absolute time of when the
> element was put to PLAYING. This does not necessarily correspond to
> the time when the first frame was grabbed/produced.
> So the use of gst_segment_to_running_time is correct (it counts from
> the first frame as far as I can tell) but the use of
> gst_element_get_base_time is not correct.

See above, running_time + base_time should always be exactly the clock
time when the buffer was captured. When you timestamp the buffers you
have to ensure that, plus additionally accomodate for the latency in
the pipeline by properly setting it on the source (or replying to the
LATENCY query).

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151023/d4f2a00d/attachment.sig>