Only last few dash chunks being played by shaka player

[parth2094]

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

What version of Shaka Player are you using?: v2.5.0-beta2

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?: comparing the result of both

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

What browser and OS are you using?: Chrome, mac OS

What are the manifest and license server URIs?:

What did you do?
Generated dash chunks and live manifest. The duration is 10 hr long and about 3601 chunks

What did you expect to happen?
Based on the current time offset from the time of generation, I expect the shaka player to calculate which chunk to play. So if it is 2 hrs from time of generation, I expect shaka player to play that chunk.

What actually happened?
The shaka player that I installed using instructions here plays only the last 3-4 chunks. I can see in the network tab it fetches 3598, 3599, 3600, 3601.m4a.
In the demo app i.e. https://shaka-player-demo.appspot.com/demo/#build=uncompiled it works fine as expected i.e. the chunks is played based on what the time offset is from the time of generation.

And the same issue repros with dash player as well what happens with the shaka player installed on my mac and being served by node js.

https://shaka-player-demo.appspot.com/demo/#asset=https://storage.googleapis.com/wvtemp/kqyang/514_user/master.mpd;lang=en-US;build=uncompiled
The above URL was tried by the shaka packager team to help me. And it worked. The dash data that I provided for this can be found here: https://drive.google.com/drive/folders/1h8hpazrUNANvJo0ozE8aLSHAK7IT5zMK?usp=sharing

The folder has master.mpd and the chunks to be played.
Can you please help me understand why is this behaviour happing on shaka player installed on my mac. Same happens with dash player but the files seem to be fine as the demo app can play them as expected.

[joeyparrish]

We can't reproduce a live stream issue if you have a static snapshot of the live content. But I can take a guess at the problem.

If you get correct chunks played in the hosted demo, but not your own application, you may be missing some configuration. In particular, the clock sync configuration.

Clock sync is critical to live streaming. You can't trust your users to have the correct time set, and sometimes, even your own clock as a developer is wrong. Clock sync provides a way to correct the client clock to sync with the server clock.

There are two main ways to accomplish clock sync: in the manifest, or through configuration.

In the manifest, you can use the <UTCTiming> element to indicate to the player how to do clock sync. See the DASH spec or the configuration documentation of your packager for details on how to set this up.

Without support from the packager to put <UTCTiming> in the manifest, you can set the manifest.dash.clockSyncUri field to any URL hosted on a server with the same clock as your content. For example, if your packager has an accurate clock, this could be any URL on any server with an accurate clock (and CORS enabled so you can read the Date header). Here's how our demo app sets this value:

player.configure(
    'manifest.dash.clockSyncUri',
    'https://shaka-player-demo.appspot.com/time.txt');

Does this help?

[parth2094]

Clock sync is critical to live streaming. You can't trust your users to have the correct time set, and sometimes, even your own clock as a developer is wrong. Clock sync provides a way to correct the client clock to sync with the server clock.

I have generated the dash files using shaka packager on cloud machine, copied the files to my local machine and have hosted the server on the same local machine. So the manifest needs to sync the client clock with my local machine(acting as the server) or the cloud machine (where the dash files were generated)?

In the manifest, you can use the <UTCTiming> element to indicate to the player how to do clock sync. See the DASH spec or the configuration documentation of your packager for details on how to set this up.

I am using shaka packager. Here is the command I used
'in=/media/test/data/inputAudio.mp4,stream=audio,init_segment=/media/dashWithUTCTiming/init.m4a,segment_template=/media/dashWithUTCTiming/$Number$.m4a' —segment_duration 10 --time_shift_buffer_depth=36000 --mpd_output /media/dashWithUTCTiming/master.mpd --utc_timing urn:mpeg:dash:utc:http-iso:2014=https://d2pqwv4o8zcpge.cloudfront.net/iso-timestamp.

The value of utc_timing points to the current UTC time always. I thought this will work as the cloud machine I used to generate dash chunks has clock as per UTC

Attaching the generated mpd in txt format.
mpd.txt

After running the above command and using the generated mpd (attached above), I still face the same issue of only the last few chunks being played.

Without support from the packager to put <UTCTiming> in the manifest, you can set the manifest.dash.clockSyncUri field to any URL hosted on a server with the same clock as your content. For example, if your packager has an accurate clock, this could be any URL on any server with an accurate clock (and CORS enabled so you can read the Date header). Here's how our demo app sets this value:

player.configure(
    'manifest.dash.clockSyncUri',
    'https://shaka-player-demo.appspot.com/time.txt');

Haven't tried this yet. In which file do I need to do this?

Few additional questions:

1. If there is a mis match in the client and server clock, I still expect some chunk to fetched based on the wrong calculation, but in my case the browser is always fetching the last few chunks. Can you please explain this as well? After packaging using utc_timing, the issue still persisted, hence I also updated the utc_timing tag in the mpd with this: UTCTiming schemeIdUri="urn:mpeg:dash:utc:direct:2014" value="2018-12-14T10:13:08Z"/> , where the time is the UTC time at which I tried it. This was about an hour after generating the files and the file is 10 hr long, so if some minutes of mismatch is fine, then shouldn't this have worked?

2. Just curious why is this flag known as utc_timing? Is it something to do with utc timezone? From the definition it just seems like setting the clock of client exactly as that of server.

[theodab]

You should put that configuration after creating the player, but before loading.

So, as you said you were following the tutorial, you could end up with something like...

function initPlayer() {
  // Create a Player instance.
  var video = document.getElementById('video');
  var player = new shaka.Player(video);

  // Configure to add a clock sync uri.
  player.configure(
      'manifest.dash.clockSyncUri',
      'https://shaka-player-demo.appspot.com/time.txt');

  // Attach player to the window to make it easy to access in the JS console.
  window.player = player;

  // Listen for error events.
  player.addEventListener('error', onErrorEvent);

  // Try to load a manifest.
  // This is an asynchronous process.
  player.load(manifestUri).then(function() {
    // This runs if the asynchronous load is successful.
    console.log('The video has now been loaded!');
  }).catch(onError);  // onError is executed if the asynchronous load fails.
}

[shaka-bot]

@parth2094 Does this answer all your questions? Can we close the issue?

[parth2094]

@theodab @joeyparrish

In the manifest, you can use the <UTCTiming> element to indicate to the player how to do clock sync. See the DASH spec or the configuration documentation of your packager for details on how to set this up.

I tried this : <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="http://127.0.0.1:8080"/>
I am serving the dash chunks through localhost so this should have worked as it will sync with server time. But this didn't work

Without support from the packager to put <UTCTiming> in the manifest, you can set the manifest.dash.clockSyncUri field to any URL hosted on a server with the same clock as your content. For example, if your packager has an accurate clock, this could be any URL on any server with an accurate clock (and CORS enabled so you can read the Date header). Here's how our demo app sets this value:

player.configure(
    'manifest.dash.clockSyncUri',
    'https://shaka-player-demo.appspot.com/time.txt');

This is what I tried in myapp.js and this also didn't work.
player.configure( 'manifest.dash.clockSyncUri', 'http://127.0.0.1:8080');

What else could I be missing. What else informartion can I provide you that will enable you to help with the root cause?

[TheModMaker]

We added a feature to ignore the availabilityStartTime and use the segment list in the manifest to determine the live edge. This allows us to play content that has bad clock sync issues (which is unfortunately common). This means that if your manifest specifies all 10 hours of content, we'll play at the end, even if the availabilityStartTime and the current time says to only play at 2 hours in.

Really, your packager should only generate content in real time. I think FFmpeg has an input flag of -r to limit output to real time if you have all the input at once.

We currently don't have a way to disable this behavior, so we should add a flag. You can verify my guess by using the v2.4.x version locally instead of master.

[shaka-bot]

@parth2094 Does this answer all your questions? Can we close the issue?

[parth2094]

We added a feature to ignore the availabilityStartTime and use the segment list in the manifest to determine the live edge.

Was this added in v2.5.x ?

This means that if your manifest specifies all 10 hours of content, we'll play at the end, even if the availabilityStartTime and the current time says to only play at 2 hours in.
Really, your packager should only generate content in real time. I think FFmpeg has an input flag of -r to limit output to real time if you have all the input at once.

I am using shakapackager to generate dash output. I am a little confused here. Is it not possible to generate a 10 hr long dash output with a live manifest which should from the availabilityStartTime be able to serve dash chunks till 10 hrs? How else must the player fetch the chunks reading the mpd by not making use of availabilityStartTime ?

[parth2094]

We currently don't have a way to disable this behavior, so we should add a flag. You can verify my guess by using the v2.4.x version locally instead of master.

Thanks a lot for pointing this out. v2.4.5 version of shaka player worked for me with and without adding UTCTiming flag.

1. How can I make this work with the latest version of shaka player?
2. If the new master version ignores availabilityStartTime, can't PublishTime be used to calculate the right chunk? How do availabilityStartTime and PublishTime differ in their use?
3. Is there a plan to fix this issue in future? This feature is critical to us and hence we need a stable option.

Thanks!!

[TheModMaker]

I am using shakapackager to generate dash output. I am a little confused here. Is it not possible to generate a 10 hr long dash output with a live manifest which should from the availabilityStartTime be able to serve dash chunks till 10 hrs? How else must the player fetch the chunks reading the mpd by not making use of availabilityStartTime ?

Let's say you have a manifest that has 3 hours of media in it that are from 2-5 hours into the live stream. The manifest specifies these segments for download by the client. Let's also say the availabilityStartTime is 3 hours ago. This means the "live edge" is at 3 hours, or is playing at 1 hour into the segments in the manifest. So there are 2 hours of segments left in the manifest. But with our new feature we ignore it and start playing at 5 hours into the live stream, at the end of the available segments.

|---------------------------------------------------------->
|                      |-------------- Segments -----------|
|---------------------------------------------------------->
                                   | Live edge
0          1           2           3           4        5
                     Time (hours)

Most live content is being generated in real time. The manifest gets updated every few seconds, adding new segments for us to play. So we should start playing at the last segment in the first manifest so we have the shortest delay between generation and playback.

But if you are generating a live stream from VOD that you have in advance, then your manifest may have many more segments than should be played. In this case, we should use the availabilityStartTime to determine where to start playing.

1. How can I make this work with the latest version of shaka player?

You can't. I'm working on adding a flag to disable our new live fixing so your content will work (delays due to the holidays).

2. If the new master version ignores availabilityStartTime, can't PublishTime be used to calculate the right chunk? How do availabilityStartTime and PublishTime differ in their use?

We don't know if we can trust publishTime and some manifests don't have it. It is supposed to be when the manifest is generated, but that may not be "now". For example, some live manifests don't need updating, but the "live edge" is still moving forward.

The current "live edge" is equal to now - availabilityStartTime. But this only works if the client's clock is the same as the server's. publishTime is just the time the manifest is generated. For many live manifests this will be the live edge since the manifest is updated every few seconds; but some manifests don't need updating and so it won't be correct.

3. Is there a plan to fix this issue in future? This feature is critical to us and hence we need a stable option.

Yep, I'll add it soon and it will appear before the v2.5 release.