Playback Stalls For Few Seconds When Playback Initiated

[waxidiotic]

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

Yes

What version of Shaka Player are you using?:

• v2.3.5 in the current production version of JW Player
• Also tested with v2.4.5, v2.5.0-beta2 and the current master branch

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?:

Reproduced with both

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

n/a

What browser and OS are you using?:

• macOS Mojave 10.14.1
• Chrome 70.0.3538.102
• Firefox 63.0.1
• Safari 12.0.1

What are the manifest and license server URIs?:

• Manifest: https://cdn-test.online.meo.pt/sdash/LIVE%24SIC_Noticias/index.mpd/Manifest?device=DASH&start=LIVE&end=END
• No license server necessary

What did you do?

• In JW Player, configure the player to autostart
• In Shaka demo app or using just the compiled version, click Play as soon as player appears

What did you expect to happen?

• If the pause button appears to denote that the player is playing, I expect the playback to immediately begin

What actually happened?

• Video hangs on first frame for upwards of 5 seconds before beginning
• No audio can be heard during these few seconds
• Using the debug compiled version with V2 logging, nothing appeared in the console to explain what was happening

[fadomire]

i had a similar issue, maybe it is not the same case but i had the startAtSegmentBoundary option set to true

[joeyparrish]

I'm getting HTTP 504 errors from your server. Each one takes fully 30 seconds. Could it be that the hang is caused by an overwhelmed server, load-balancer, or CDN? Here's a screenshot:

Please try again and use the network panel in your browser to monitor the server's response codes and response times. If this server issue is resolved and you still have playback problems, please let us know and we can look again.

[waxidiotic]

@joeyparrish I'm getting the same (504) response now, but it wasn't this way when I submitted it. Let me reach out to the customer to see what's going on.

[joeyparrish]

Okay. I'll put it back in the triage queue for whoever is on duty after me.

[waxidiotic]

Here's an updated URL: https://cdn-test.online.meo.pt/sdash/LIVE%24Trailers_VideoClube/index.mpd/Manifest?device=DASH&start=LIVE&end=END

[joeyparrish]

With the new URL, I can't see anything obviously wrong. The times below are measured from my very fast workstation on my very fast internet connection, so they may vary and could be much longer for others.

I'm seeing a load latency of about 2-3 seconds as measured by Shaka Player. You can measure this state yourself by turning setting the log level to "Debug" in the demo app UI under "configuration" and observing the JS console. Load latency here is the time from the load() call to the video element's loadeddata event, which corresponds to having anything buffered at all. This includes fetching and parsing the manifest, fetching and consuming init segments, and fetching and consuming the very first media segments (1 audio, 1 video). At this point, you should see the first frame of video on the screen and a buffering spinner.

Is this the state which you are calling a stall?

From that point until we exit the buffering state is about 2-3 seconds more for me. This includes fetching additional media segments to meet the buffering goals expressed in the manifest and the player configuration. The manifest has a minBufferTime attribute of 6 seconds, so we cannot start playback until 6 seconds of media has been buffered.

If it's this initial buffering which takes too long for you, you should reduce the minBufferTime attribute in the DASH manifest to something more reasonable.

If you can't control the content, you can override minBufferTime with the manifest.dash.ignoreMinBufferTime config in the Player. (This was released in v2.5.0-beta2. See issue #1547 and PR #1581.) For example:

// DASH minBufferTime will have no effect if we set this field before loading:
player.configure('manifest.dash.ignoreMinBufferTime', true);
// We can now control initial buffering purely through this field:
player.configure('streaming.rebufferingGoal', 2 /* seconds */);

Does this help?

[waxidiotic]

@joeyparrish Yeah, that sounds like the point in which it looks like our player is stalling, because we're not displaying the buffer spinner. However, I'm confused why the playback of the stream below starts right away for us in our player:

https://wowzaec2demo.streamlock.net/live/bigbuckbunny/manifest_mpm4sav_mvtime.mpd

It also has a minBufferTime of 6 seconds.

[joeyparrish]

There are three major, meaningful differences between those two pieces of content that greatly influence startup latency: presentation delay, segment size, and bitrate.

---

Presentation delay

The stream which isn't stalling has a suggestedPresentationDelay attribute of 20 seconds. The which which is stalling has no such attribute, so we wind up with our (configurable) default of 10 seconds. You can configure the default presentation delay like so:

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

(If the default presentation delay is less than 1.5 * minBufferTime, we use 1.5 * minBufferTime, to make sure we are able to reach our startup goal without falling behind the presented live edge.)

The presentation delay is very important. It influences how far ahead the Player can buffer at the live edge, which then indirectly influences how quickly we can reach the minBufferTime goal.

The live edge on the server side is the start of the latest segment that has been written to the CDN. The live edge for the Player is the start of the latest segment in the manifest minus the presentation delay. We will start playback at that point, but we can buffer ahead of that up until the the latest segment in the manifest. So if presentation delay is 20 seconds, we can fetch up to 20 seconds of content ahead of what is presented to the user.

---

Segment size

When you factor in segment size, you get another major difference: the stream that works better has larger segments (10 seconds vs 2 seconds). So you need fewer of them to start playback.

Let's show these startup factors in a table. For the working stream:

segment size	bleeding edge (server)	live edge (playback)	segments available at start	segments needed to reach goal
10	T	T - 10 - 20	3	1

So as soon as you have 1 video and 1 audio segment, you can start playback.

Vs in the delayed stream:

segment size	bleeding edge (server)	live edge (playback)	segments available at start	segments needed to reach goal
2	T	T - 2 - 10	6	3

Here you need to have 3 video and 3 audio segments to start playback. You have the additional connection latency of 6 fetches vs 2 and the additional overhead in bandwidth of 6 MP4 structures instead of 2.

---

Bitrate

If you look at the bitrate requirements of the two streams, you'll see the final important difference. The stream which works better only has one bitrate available: 600kbit video + 96kbit audio. The other stream has 4 video streams (250kbit, 600kbit, 1200kbit, and 2100kbit) + 64kbit audio. So one final table:

data to fetch (good stream, starts quickly)	min data to fetch (bad stream)	max data to fetch (bad stream)
696 kbit/s * 10 s = 6960 kbit	316 kbit/s * 6 s = 1896 kbit	2164 kbit/s * 6 s = 12984 kbit

So if your internet connection is fast, the bad stream might be fetching twice as many bytes over three times as many individual requests to start playback.

[shaka-bot]

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

[waxidiotic]

This is amazing @joeyparrish. Thank you so much. I'll relay this to the customer.

[joeyparrish]

Happy to help. Should we leave the issue open for a few more days?

[waxidiotic]

@joeyparrish Nah, I think we're good.