Problem with clockSyncUri when manifest is served from CDN on live streams

Ferdinand Hernandez

unread,

Apr 11, 2017, 9:06:44 AM4/11/17

to Shaka Player Users

Hi Guys,

We are currently having problems when the CDN is caching the manifest.mpd file for 5 seconds. Shaka player fires the error below:

(video:1) cannot find segment: currentPeriod.startTime=0 lookupTime=97284

On the player.configure of the shaka player we have implemented the clockSyncUri: mpdUrl. for example:

player.configure({
                drm: {
                        servers: {
                                //'com.widevine.alpha': 'xxx',
                                'com.widevine.alpha': 'xxxx',
                                'com.microsoft.playready': 'xxx'
                        }
                        /**
                        ,
                        advanced: {
                                'com.widevine.alpha': {
                                        'videoRobustness': 'SW_SECURE_CRYPTO',
                                        'audioRobustness': 'SW_SECURE_CRYPTO'
                                }
                        
                        }
                        **/
                },
                manifest: {
                       dash: {
                              clockSyncUri: mpdUrl
                      }
               },
                streaming: {
                        //bufferingGoal: 60,
                        //rebufferingGoal: 30

                }


        });

This happens only whenever we serve the manifest files through the CDN. And when the CDN caches it for more than 2 seconds (i.e. 5 seconds). Our segments are 6 seconds long. All other player, specifically Exoplayer works just fine.

Will implementing the UTCTiming in the manifest.mpd solve this issue? Or is there a way to configure shaka player to ignore the time and just play the available segments in the manifest?

Regards,

Ferdinand

Joey Parrish

unread,

Apr 11, 2017, 12:20:52 PM4/11/17

to Shaka Player Users

Hi Ferdinand,

If the manifest is cacheable, then that is not a good URI to use for clock sync. The clock sync URI can be any reliable, non-cacheable URI you control.

Implementing UTCTiming could also be a solution, but it is worth noting that setting a clock sync URI through configure is equivalent to this UTCTiming element in the manifest:

This scheme uses an HTTP HEAD request to read the Date header.

There are other schemes you could implement through UTCTiming in the manifest, however all of them would be adversely affected by caching. (The "http-iso" and "http-xsdate" schemes will make an HTTP request for the URI stored in the "value" attribute and interpret the body of the response as a date string, so that URI must not be cached. The "direct" scheme includes a date string in the "value" attribute of the element, so the manifest itself must not be cached.)

Does this help clarify the situation?

-Joey

--
You received this message because you are subscribed to the Google Groups "Shaka Player Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shaka-player-users+unsub...@googlegroups.com.
To post to this group, send email to shaka-player-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shaka-player-users/1fb4bb2a-774b-41b7-9bf7-a2fa9fcf86ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Przemysław Sobala

unread,

Jun 19, 2017, 7:38:47 AM6/19/17

to Shaka Player Users

W dniu wtorek, 11 kwietnia 2017 18:20:52 UTC+2 użytkownik Joey Parrish napisał:

Hi Ferdinand,

If the manifest is cacheable, then that is not a good URI to use for clock sync. The clock sync URI can be any reliable, non-cacheable URI you control.

Implementing UTCTiming could also be a solution, but it is worth noting that setting a clock sync URI through configure is equivalent to this UTCTiming element in the manifest:

<UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="YOUR_CLOCK_SYNC_URI" />

This scheme uses an HTTP HEAD request to read the Date header.

There are other schemes you could implement through UTCTiming in the manifest, however all of them would be adversely affected by caching. (The "http-iso" and "http-xsdate" schemes will make an HTTP request for the URI stored in the "value" attribute and interpret the body of the response as a date string, so that URI must not be cached. The "direct" scheme includes a date string in the "value" attribute of the element, so the manifest itself must not be cached.)

Does this help clarify the situation?
-Joey

Hi

Just to clarify: what method of client time synchronization can I use when my manifests are cached for 1 second?

If I use the "direct" scheme, does player perform time synchronization on every manifest refresh? If so, with cached manifest it could have a glitch...

--

regards

Przemysław Sobala

Joey Parrish

unread,

Jun 19, 2017, 2:50:35 PM6/19/17

to Shaka Player Users

On Mon, Jun 19, 2017 at 4:38 AM, Przemysław Sobala <przemysl...@gmail.com> wrote:

Just to clarify: what method of client time synchronization can I use when my manifests are cached for 1 second?
If I use the "direct" scheme, does player perform time synchronization on every manifest refresh? If so, with cached manifest it could have a glitch...

Correct. If the manifest is cached, both "direct" method (time in the manifest itself) and "head" method (time in the Date header of the manifest) could potentially be cached.

If you know it will only be cached for 1 second, then you know your clients will only be as much as 1 second behind.

Does this help?

-Joey

Przemysław Sobala

unread,

Jun 20, 2017, 10:03:42 AM6/20/17

to Shaka Player Users

That's what my question was about: If a client gets fresh manifest with current time ("direct" scheme) and later, after a few seconds, it gets a cached manifest with current time +- 0.(9) sec (due to 1 sec manifest cache time), then, with on manifest update time synchronization, client will fast-forward or pause for that +- 0.(9)sec ?

Joey Parrish

unread,

Jun 20, 2017, 12:37:49 PM6/20/17

to Shaka Player Users

I checked the source code, and it appears that we do not resynchronize the clock on each manifest update. This makes sense, because the timestamps in the headers are only accurate to the second, and we don't want our understanding of the live edge to wobble.

--

You received this message because you are subscribed to the Google Groups "Shaka Player Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shaka-player-users+unsub...@googlegroups.com.
To post to this group, send email to shaka-player-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shaka-player-users/2d44d742-3d59-4b51-ad18-376f4cee8942%40googlegroups.com.

Przemysław Sobala

unread,

Jun 26, 2017, 5:14:14 AM6/26/17

to Shaka Player Users

W dniu wtorek, 20 czerwca 2017 18:37:49 UTC+2 użytkownik Joey Parrish napisał:

I checked the source code, and it appears that we do not resynchronize the clock on each manifest update. This makes sense, because the timestamps in the headers are only accurate to the second, and we don't want our understanding of the live edge to wobble.

Great! So I'm going to synchronize my clients based on UTCTiming and "direct" scheme inside manifests that are cached for 1 second.

--

regards

Przemysław Sobala

Reply all

Reply to author

Forward