[Bug 762910] onvifparse: extract and apply onvif timestamp
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Fri Mar 4 08:18:18 UTC 2016
https://bugzilla.gnome.org/show_bug.cgi?id=762910
--- Comment #2 from Nicola <lists at svrinformatica.it> ---
(In reply to Sebastian Dröge (slomo) from comment #1)
> Review of attachment 322727 [details] [review]:
thanks for the review
>
> This shouldn't be the default, it will break playback unless a) basetime of
> the pipeline is 0 and b) the pipeline uses a clock the returns UNIX time
> (e.g. the real-time system clock).
>
is a property such as apply-onvif-timestamp as enum:
0 - no
1 - ntp time
2 - unix time
good enough?
the first option will preserve the timestamp generated in rtspsrc
> ::: gst/onvif/gstrtponvifparse.c
> @@ +122,3 @@
> + self->last_onvif_timestamp =
> + timestamp_seconds * GST_SECOND + timestamp_nseconds * GST_NSECOND -
> + (2208988800LL * GST_SECOND);
>
I think this could be refactored this way
ntptime = GST_READ_UINT64_BE (data);
unixtime = ntptime - (G_GUINT64_CONSTANT (2208988800) << 32);
self->last_onvif_timestamp = gst_util_uint64_scale (unixtime, GST_SECOND,
(G_GINT64_CONSTANT (1) << 32));
the result is the same but this is the way gstreamer already use in other
elements
> Question is also: why convert to UNIX time?
in my use case I need to extract a recording, having the absolute time for each
buffer allow to accept/drop buffers as needed, unix time is convenient to me
since I can simply build a datetime object from it
>You don't know what your
> pipeline clock is using, it might very well use NTP times.
>
> @@ +148,3 @@
> + }
> + if (GST_CLOCK_TIME_IS_VALID (buf->pts)) {
> + buf->pts = self->last_onvif_timestamp;
>
> GST_BUFFER_PTS (buf) = ...
ok
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list