Live Playing with Jumping forward

[mjaddani]

Have you read the FAQ and checked for duplicate open issues?: Yes

What version of Shaka Player are you using?: 2.4.2

Can you reproduce the issue with our latest release version?: Yes

Can you reproduce the issue with the latest code from master?: Yes

Are you using the demo app or your own custom app?: both

If custom app, can you reproduce the issue using our demo app?: Yes

What browser and OS are you using?: Chrome 67

What are the manifest and license server URIs?: i send you by email.

What did you do?
When i play this live manifest with widevine DRM behind a slow proxy. We have a lot error
"Jumping forward 3.004999876022339 seconds to catch up with the seek range."

If i don't play it behind a proxy, if i do pause play, and we reproduce also the same effect.

What did you expect to happen?

What actually happened?

[joeyparrish]

This is because you have no suggestedPresentationDelay attribute in your manifest, combined with a timeShiftBufferDepth of 10s. timeShiftBufferDepth of 10s means that only 10s of content is accessible to the client at a time.

To compensate for the time it takes clients to get started, you use the suggestedPresentationDelay attribute in DASH. Your manifest doesn't have one specified, so we default to 10s. You can change this default through configuration. For example:

player.configure('manifest.dash.defaultPresentationDelay', 30);

The effect of presentation delay is that the live edge of taken backward by that amount. So for 10s, the live edge is 10s behind the content available on the server. This means the client can buffer 10s ahead of what it can play.

However, since your timeShiftBufferDepth is only 10s, that means that only 10s of content is available, and playback happens at the left edge of that range. Your timeShiftBufferDepth should be larger than your presentation delay.

In the latest code on master, both of these parameters can be tuned through configuration. (Subject to us fixing the bug we just discovered in #1177.) Here's an example that works well for your stream with Chrome's "Fast 3G" network emulation:

player.configure({
  manifest: {
    availabilityWindowOverride: 20,
    dash: {
      defaultPresentationDelay: 10
    }
  }
});

With that config and the fix for #1177 (out soon), your content can be played. You could also fix this by tweaking your manifest like so:

<MPD
  xmlns="urn:mpeg:dash:schema:mpd:2011"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:cenc="urn:mpeg:cenc:2013"
  profiles="urn:mpeg:dash:profile:isoff-live:2011"
  type="dynamic"
  availabilityStartTime="1970-01-01T00:00:00Z"
  publishTime="2018-07-20T17:57:05Z"
  minimumUpdatePeriod="PT2S"
  maxSegmentDuration="PT2.006S"
  minBufferTime="PT6S"
  timeShiftBufferDepth="PT20S"
  suggestedPresentationDelay="PT10S">

[mjaddani]

Many thanks, i will test it It’s the same think for chromecast because chromecast use shaka ? Best regards Le ven. 20 juil. 2018 à 20:29, Joey Parrish <notifications@github.com> a écrit :

…

This is because you have no suggestedPresentationDelay attribute in your manifest, combined with a timeShiftBufferDepth of 10s. timeShiftBufferDepth of 10s means that only 10s of content is accessible to the client at a time. To compensate for the time it takes clients to get started, you use the suggestedPresentationDelay attribute in DASH. Your manifest doesn't have one specified, so we default to 10s. You can change this default through configuration. For example: player.configure('manifest.dash.defaultPresentationDelay', 30); The effect of presentation delay is that the live edge of taken backward by that amount. So for 10s, the live edge is 10s behind the content available on the server. This means the client can buffer 10s ahead of what it can play. However, since your timeShiftBufferDepth is only 10s, that means that only 10s of content is available, and playback happens at the left edge of that range. Your timeShiftBufferDepth should be larger than your presentation delay. In the latest code on master, both of these parameters can be tuned through configuration. (Subject to us fixing the bug we just discovered in #1177 <#1177>.) Here's an example that works well for your stream with Chrome's "Fast 3G" network emulation: player.configure({ manifest: { availabilityWindowOverride: 20, dash: { defaultPresentationDelay: 10 } } }); With that config and the fix for #1177 <#1177> (out soon), your content can be played. You could also fix this by tweaking your manifest like so: <MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cenc="urn:mpeg:cenc:2013" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="dynamic" availabilityStartTime="1970-01-01T00:00:00Z" publishTime="2018-07-20T17:57:05Z" minimumUpdatePeriod="PT2S" maxSegmentDuration="PT2.006S" minBufferTime="PT6S" timeShiftBufferDepth="PT20S" suggestedPresentationDelay="PT10S"> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1493 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AT5aXENtE3aNBZypLMbvAzU_LqW0N56jks5uIiGWgaJpZM4VSOGe> .

[joeyparrish]

The Cast Application Framework uses Shaka Player internally for DASH. I'm not sure if you are using that or not. You can also build custom cast receivers based on Shaka Player.

[mjaddani]

With this params, the content works

[joeyparrish]

Thanks for letting us know!

[mjaddani]

On the same platform, i'have an another content who don't work with your params. I'send you by email the url. Thanks for your help