Fix support for relative paths in clock sync URIs

[asdftu]

i checked the code and found that shaka got the playheadtime by calculate "Date.Now - availabilityStartTime - maxSegmentDuration" ,
when my local time is faster or the time of server side is slower, shaka will never found the playback segment.

please help to check,
Thanks
Logan

[asdftu]

1. adjust machine time 5 minutes ahead.
2. play http://wowzaec2demo.streamlock.net/live/bigbuckbunny/manifest_mpm4sav_mvtime.mpd

[joeyparrish]

Your manifest does not contain a UTCTiming element, which is how manifests specify time sync between client and server.

In v2.0.0-beta2 we introduced a configuration option for situations where you cannot add UTCTiming to your manifest. You can instead configure a URI for the player to use as if it came from UTCTiming.

Docs: http://shaka-player-demo.appspot.com/docs/api/shakaExtern.html#DashManifestConfiguration

A default clock sync URI to be used with live streams which do not contain any clock sync information. The "Date" header from this URI will be used to determine the current time.

Example:

player.configure({
  manifest: {
    dash: {
      clockSyncUri: 'http://foo.bar/time'
    }
  }
});

The demo app at http://shaka-player-demo.appspot.com/demo/ has a clock sync URI configured, so your manifest should work correctly on that demo regardless of your local clock. (Please let us know if it does not.)

Does this answer your question?

[asdftu]

Hi Joe,
very very thanks for your reply,

yes, it did work if i adding your configuration for playing the stream "http://wowzaec2demo.streamlock.net/live/bigbuckbunny/manifest_mpm4sav_mvtime.mpd".

but we also developed Dash Stream Server, I found that the live edge of our own stream produced by my server is slow 30 seconds(maybe the system delay from encoder to server) than the time of now,
i know this is not up to DASH standard, but i have no idea to solve this,

Is there any solutions can be done on player side under these circumstances?

Thanks
Logan

[joeyparrish]

Can you clarify what you are asking for? It sounds like you have some bug in your server, but I am not at all sure I understand.

[asdftu]

what i mean is that
my Dash Stream Server have some bugs that it produced the live streams always later 30 seconds than now.

for example,
_the NTP time is 11:10:31 2016-5-14,
and my machine time is also 11:10:31 2016-5-14,
test.mpd is the dash manifest produced by my stream server,
in the "test.mpd",
<MPD profiles="urn:mpeg:dash:profile:isoff-live:2011" type="dynamic" availabilityStartTime="2016-05-14T11:00:00Z" maxSegmentDuration="PT4.0S" publishTime="2016-05-13T11:10:31Z"> <SegmentTemplate timescale="1000" media="$RepresentationID$/Time=$Time$.m4s" initialization="$RepresentationID$/Time=init.m4s"> <SegmentTimeline> <S t="550000" d="5000" /> <S t="555000" d="5000" /> <S t="560000" d="5000" /> <S t="565000" d="5000" /> <S t="570000" d="5000" /> <S t="575000" d="5000" /> <S t="580000" d="5000" /> <S t="585000" d="5000" /> <S t="590000" d="5000" /> <S t="595000" d="5000" /> <S t="600000" d="5000" /> </SegmentTimeline> </SegmentTemplate> <Representation id="tv_3000_video" bandwidth="3000000" /> </Period>
' ' plus the availableStartTime is time of "2016-05-14T11:10:00Z",
so you see, the latest Segment is always delay 30 seconds than now.

right now, shaka request the live edge, what it request is the segment which t = 631000 , ( 631000 is the time now 11:10:31 minus the available start time 11:00:00 and unit in millisecond )

the last "" in " " is ' ',
so shaka will never get the segment what it request.

and that is my issue, i can not modify anything for the server side.
is there any ways that shaka can be compatible with these delay streams.

and as i know, shaka v1.3.0 can play these delay live streams.

[joeyparrish]

The fact that v1.3.0 miscalculated the live edge in a way that compensates for a bug in the server is not a good thing. :-)

You should provide <UTCTiming> in your manifest and synchronize the client to the UTC time the server thinks it is (the delayed time). Something like this:

<UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-iso:2014" value="/path/to/currentTime">

Where /path/to/currentTime is some endpoint in your server that delivers the current time in a form comprehensible to JavaScript's Date.parse(), for example 2016-05-14T15:15:00+0200.

[asdftu]

Thanks very much,

but it seems that i must use an absolute path not the relative path like value="/path/to/currentTime" because the relative path value doesn't work as was expected。

following code is line 1077 in dash_parser.js:
var schemesAndValues = elems.map(function(elem) { return { scheme: elem.getAttribute('schemeIdUri'), value: elem.getAttribute('value') };

what it requests is the value but not the value concat with baseUrl
this.requestForTiming_(value, 'HEAD');

But, if i use the absolute path, there will be another issue, if i want use the CDN to delivery the mpd and content, it will be confused to set the absolute value

[joeyparrish]

Okay, so it seems we need to fix support for relative paths.

[joeyparrish]

Hi @asdftu, please try again with the latest from master.

[asdftu]

OK, Thanks very much!
i will test it.