After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781181 - dashdemux: Use Date in http-header as UTC now
dashdemux: Use Date in http-header as UTC now
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-04-11 13:49 UTC by Seungha Yang
Modified: 2018-11-03 14:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
dashdemux: Use Date in http-header as UTC now (8.92 KB, patch)
2017-04-11 13:51 UTC, Seungha Yang
none Details | Review
dashdemux: Use Date in http-header as UTC now (8.88 KB, patch)
2017-04-11 13:55 UTC, Seungha Yang
none Details | Review
adaptivedemux: Use Date in http-header as UTC now (12.62 KB, patch)
2017-06-02 13:07 UTC, Seungha Yang
none Details | Review

Description Seungha Yang 2017-04-11 13:49:17 UTC
Instead of system time, use http-header to estimate wall-clock.
System time might much differ from UTC time, depending on system.
Comment 1 Seungha Yang 2017-04-11 13:51:20 UTC
Created attachment 349675 [details] [review]
dashdemux: Use Date in http-header as UTC now
Comment 2 Seungha Yang 2017-04-11 13:55:22 UTC
Created attachment 349676 [details] [review]
dashdemux: Use Date in http-header as UTC now
Comment 3 Sebastian Dröge (slomo) 2017-04-11 14:03:11 UTC
What does this solve, and isn't that exactly why the DASH extensions exist that allow you to specify the remote clock? (As NTP clock, HTTP HEAD request to somewhere, and 20 other ways)
Comment 4 Seungha Yang 2017-04-11 14:23:20 UTC
(In reply to Sebastian Dröge (slomo) from comment #3)
> What does this solve, 

The difference between UTC now and availabilityStartTime is set as fragment wating time. https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/dash/gstdashdemux.c#n1926

The problem is, if UTCTiming element was not provided ans also system time is much incorrect, we cannot start streaming.

> and isn't that exactly why the DASH extensions exist
> that allow you to specify the remote clock? (As NTP clock, HTTP HEAD request
> to somewhere, and 20 other ways)

clock source (NTP. HTTP HEAD or etc) related things are signalled by UTCTiming element in MPD. But if UTCTiming element does not provided by server, HTTP HEADER was one of the bast and simplest way to sync them from my experience.
Comment 5 Sebastian Dröge (slomo) 2017-04-11 14:26:38 UTC
That makes sense, yes
Comment 6 Sebastian Dröge (slomo) 2017-05-09 12:53:41 UTC
Review of attachment 349676 [details] [review]:

You probably want to do the same for any headers received for the actual fragments, or whatever GstURIDownloader downloads (or at least updated playlists/manifests)?

Also why do you do some parts in dashdemux, and others in the base class? Looks like it could all be done in the baseclass instead?
Comment 7 Seungha Yang 2017-05-09 13:23:24 UTC
(In reply to Sebastian Dröge (slomo) from comment #6)
> Review of attachment 349676 [details] [review] [review]:
> 
> You probably want to do the same for any headers received for the actual
> fragments, or whatever GstURIDownloader downloads (or at least updated
> playlists/manifests)?
I think "do it per manifest update" seems great suggestion.

> Also why do you do some parts in dashdemux, and others in the base class?
> Looks like it could all be done in the baseclass instead?

It could be done in baseclass and it might seem to better than in dashdemux.
But, the reason I did it in dashdemux was, 
- parsing "Date" in http header is required only for dash as far as I know,
and the code for parsing "Date" is already implemented in dashdemux. Actually, I don't have much knowledge of mss spec :( But HLS has no live sync scheme over http header. So I didn't think it's good idea that moving it into baseclass only for dash.
If you think moving it to baseclass seems better, I will :)
Comment 8 Edward Hervey 2017-05-30 13:30:19 UTC
Shouldn't we have some satefy measures in place ? What if the server returns completely wrong dates ?

One could assume the "now" returned by the server can't be more than a few minutes away from the current local time, no ?
Comment 9 Tim-Philipp Müller 2017-05-30 13:45:31 UTC
Is a DASH client supposed to make assumptions about the current wallclock time/date?

The client might be a device where the time/date hasn't been set properly or not at all, no?
Comment 10 Sebastian Dröge (slomo) 2017-05-30 14:10:39 UTC
I'd rather trust the server (that is serving the live stream, so it can't be that wrong) than a random client clock.
Comment 11 Sebastian Dröge (slomo) 2017-05-30 14:14:07 UTC
Also especially if the server does TLS, a wrong clock would be fatal :) I think it's safe to assume that the server clock is Ok in relation to the stream.
Comment 12 Seungha Yang 2017-06-02 13:07:21 UTC
Created attachment 353079 [details] [review]
adaptivedemux: Use Date in http-header as UTC now
Comment 13 GStreamer system administrator 2018-11-03 14:07:10 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/544.