Time sync - Can't load stream without UTCTiming

[hussam-i-am]

Occurs in Shaka v2.0.0, also reproducible in v2.0.1 demo page.

Trying to load a live stream without UTCTiming elements, which was supported in Shaka 1.6. An error loads and produces this in the logs

(video:1) cannot find segment: currentPeriod.startTime=0 lookupTime=474.2109999656677
shaka.media.StreamingEngine.lookupSegmentPosition_ @ streaming_engine.js:1004
shaka.media.StreamingEngine.getSegmentReferenceNeeded_ @ streaming_engine.js:956
shaka.media.StreamingEngine.update_ @ streaming_engine.js:864
shaka.media.StreamingEngine.onUpdate_ @ streaming_engine.js:749

(audio:2) cannot find segment: currentPeriod.startTime=0 lookupTime=474.2109999656677
shaka.media.StreamingEngine.lookupSegmentPosition_ @ streaming_engine.js:1004
shaka.media.StreamingEngine.getSegmentReferenceNeeded_ @ streaming_engine.js:956
shaka.media.StreamingEngine.update_ @ streaming_engine.js:803shaka.media.StreamingEngine.onUpdate_ @ streaming_engine.js:749

[joeyparrish]

@hghazzi, can you please provide a manifest URL so that we can try to reproduce your issue?

[hussam-i-am]

https://raw.githubusercontent.com/hghazzi/hghazzi.github.io/master/manifest.mpd

[hussam-i-am]

@joeyparrish Also, tested against the master branch to confirm if the issue was already resolved and looks like it hasn't.

[birme]

@hghazzi: Looking at the manifest you have the AvailabilityStartTime = 2016-11-30T20:22:52 (1480537372 as unix TS). The first segment interpreted in seconds (109017062370 / 90000) = 1211300.693 which would then correspond to 1480537372 + 1211300.693 = 1481748672.693 = 2016-12-14T20:51:00.

Was it expected that the first segment corresponds to that time in your live (I presume) stream? If that is the case I suspect the clock on your computer was not in synch with the encoder/server.

Shaka 2.x provides a way to provide an endpoint if the UTCTiming is not included in the manifest by specifying a clockSyncUri in manifest configuration: https://shaka-player-demo.appspot.com/docs/api/shakaExtern.html#DashManifestConfiguration

Try specify a clockSyncUri endpoint there (could be the same as the manifest URI) and see if it works better. Requires that the Date header is available in a HEAD request (and also exposed in case of CORS restrictions).

[joeyparrish]

When I accessed the stream at 19:41:18 GMT, my calculations based on availabilityStartTime say I was 415479 seconds into the presentation.

The oldest segment in the manifest starts at 39980186100 with timescale 90000, so that equates to time 444224, which is 28745 seconds in the future, or about 8 hours.

Your encoder's clock is therefore roughly 8 hours ahead of actual current time. Either you can fix the time on your encoder or you can use UTCTiming to synchronize the client with the encoder's time.

[hussam-i-am]

Thanks for the info, @joeyparrish @birme. We're following on it to see if the issue will be resolved with clockSyncUri

[TheModMaker]

@hghazzi does clockSyncUri fix the issue for you? Can we close this?

[hussam-i-am]

@TheModMaker Looks like we need to get a new stream with the issue to test it out. Will close this issue until we can follow up on it.

[hussam-i-am]

Hey @joeyparrish @TheModMaker, I got another stream where I was able to reproduce this issue. I tried to set clockSyncUrl to use manifest uri, but did not work. It does the HEAD request and I see the Date header in the dev tool Network tab, but not in the response header in the code. Looks like a CORS issue, but I would have expected that it would work. Here's the manifest:

http://convoypoc.vdc.netstream.com/__cl/dummy/__c/6085/__op/dash/__f/manifest.mpd

This does work in the DASH-IF player, though not very well.

[hussam-i-am]

Would this be resolved by #555? If so, any workarounds for the time being?

[joeyparrish]

Cross-origin headers must be exposed explicitly by the server. To be used for clock sync, your manifest server would need to add:

Access-Control-Expose-Headers: Date

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Access-Control-Expose-Headers

[hussam-i-am]

Thanks @joeyparrish, we will relay all the possible updates that can be made to the encoders and/or servers to our customers, so that they know how to troubleshoot it on their end.

However, on our player, we want to be able to be able to error out if we encounter this issue with more live streams (we've encountered this twice so far).

Based on the calculation mentioned in #386 by @tdrews
In general, the t= values in each SegmentTimeline (after dividing by timescale) should be around now - availabilityStartTime. This can be accomplished by setting availabilityStartTime to the publish time of the very first MPD (so long as the first timestamp in the first segment is 0).

We would like to handle this issue with live streams more gracefully, but would involve some changes in shaka-player. Either

• Be able to configure an acceptable deviation that the player will handle, and throw an error that we can use. Right now, it just infinitely buffers and outputs a console warning in the uncompiled version.

• Or expose the data that is in the PresentationTimeline object, so that we would be able to perform the calculation and error handling on our end.

Would one of these or some other solution be valuable to the player? We're happy to take this on and contribute to the project.

[joeyparrish]

Fundamentally, this is a clock sync issue. Clock sync is critical to live streaming, and you can't expect clients to request the correct segments if they don't know what time it is.

You don't have to use your manifest or encoder to sync the client's clock. You can use some other CORS-friendly URL as a time source. Really, any URL on any server you control. So long as that server and your encoder both have accurate clocks, your client's clock will be corrected.

Shaka Player is a generic DASH client, and as such, we can only reasonably support the subset of DASH which is considered interoperable. This is defined by DASH IF's Interoperability Points document, v4.0 of which states (emphasis added):

4.7.2. Service Provider Requirements and Guidelines

If the Media Presentation is dynamic or if the MPD@availabilityStartTime is present then the service shall provide a Media Presentation as follows:

• The segment availability times announced in the MPD should be generated from a device that is synchronized to a globally accurate timing source, preferably using NTP.
• The MPD should contain at least one UTCTiming element.

I hope you can understand my position. You should feel free to make whatever changes you need to in your own fork, but my team doesn't have the time or energy to implement or maintain non-standard approaches to live streaming. What we did in v1.6 was, effectively, non-standard. We did not synchronize clocks, we second-guessed the timeline presented in the manifest, and we introduced subtle and difficult-to-solve bugs because of it. It was not a sustainable approach for us.

Since v2.0, we only use the timeline as presented in the manifest, and to do that, we must have an accurate time. So the client must be able to synchronize its clock to an accurate time source on some server. As mentioned by Jonas back in December, you can configure Shaka Player to use any URL you want for time synchronization. It doesn't even have to be a CORS-friendly URL if its on the same origin as your application itself.

And finally, if your encoder's clock is still offset by 8 hours, you will ultimately need to open a support request with whoever runs that server and ask that the server's clock be fixed. It's not a difficult argument for you to make that a service you (presumably) pay for should have an accurate clock.

[hussam-i-am]

Thanks for you feedback. I agree that we should stick to the spec from DASH IOP. We will relay to our customers to ensure that their MPD files conform to it.