DASH playback hangs in video.js 7.8.4 on IE11, Edge-Chromium, and Safari

[dar1]

Description

Briefly describe the issue. DASH videos are hanging on vjs7.8.4 in a very consistent way on Win10 IE11 and Edge-Chromium, as well as MacOS Safari 13 -- the first segment plays and then the video hangs at the end of the first segment. I have experienced this with multiple DASH videos of different types (links included below) and this has been verified on multiple Win10 machines. Example links, DASH creation data, and page source code are provided below for two different videos.

Steps to reproduce

Explain in detail the exact steps necessary to reproduce the issue.

1. Use the example links or the source code below to open a DASH video using vjs7.8.4
2. Observe that playback hangs at the end of the first segment.

Results

Expected

Please describe what you expected to see. DASH videos should play to completion on vjs7.8.4 without hanging when using these browsers: Win10 IE11, Win10 Edge-Chromium, and MacOS Safari 13. I expect these DASH videos to also play properly on the same browsers if using Playready DRM

Actual

Please describe what actually happened. DASH videos hang at end of first segment on Win10 IE11, Win10 Edge-Chromium, and MacOS Safari 13. Manually jumping ahead using the seekbar will show a still frame of the video at the new time but still will not play beyond that point. The hang point is at the end of the first segment --- the two test videos had different segment lengths -- one was 4 seconds and the other was 8 seconds, and the hang point occurred at exactly 4 seconds or 8 seconds from the start of the video, respectively. The same DASH videos playback correctly when using the same vjs7.8.4 page on current versions of Chrome and Firefox browsers. The same DASH videos also playback correctly if using vjs6 with the dash plugins that were used prior to vjs7 -- specifically, the DASH videos play fine on vjs6.13.0 using the latest versions of the two dash plugins -- demo links and source for this are also provided below.
Note that I tried these same tests using Playready DRM and the results were essentially the same... vjs7 would still hang at the end of the first segment, and vjs 6.13.0 played OK when using the dash plugins. I also tried leaving the dash plugins in when using vjs7.8.4, and this did help but the results were not as consistent as when using 6.13.0.

Error output

Typically no errors are generated, the playback just hangs and displays the spinner.

Additional Information

Please include any additional information necessary here. Including the following:

versions

videojs

what version of videojs does this occur with? Problem described above is seen on vjs 7.8.4, also found it to be similar on 7.9.1 and on 7.5.4 (although 7.5.4 has the additional quirk of sometimes skipping the first few seconds when playback starts). Vjs 6.13.0 with the dash plugins (see source and links below) plays these files correctly.

browsers

what browser are affected? The problem described (hanging at end of first DASH segment) happens on: Win10 IE11, versions 11.388.19041.0 and 11.900.18362.0 Win10 Edge-Chromium, version 84.0.522.40 MacOS Safari 13 version 13.1.1

OSes

what platforms (operating systems and devices) are affected? Testing for IE11 and Edge-Chromium produced identical results on two Win10 desktops, as follows: Desktop 1: Windows 10 Pro, 2004, 19041.388 Desktop 2: Windows 10 Pro, 1909, 18363.900 Testing on Safari was done on a MacOS desktop, MacOS version 10.15.5

plugins

are any videojs plugins being used on the page? If so, please list them below. No plugins were used with the problem vjs version (7.8.4) since DASH playback capability is built-in to vjs 7.x. The same DASH videos playback fine when using vjs version 6.13.0 using these DASH plugins: dash.all, version 3.1.1 videojs-contrib-dash, version 2.11.0

////////////////////////////////////////////////////////////// My ultimate use case is to play DASH on the affected browsers with Playready DRM, which was my starting point, but I backed out the DRM from the code and saw that the problem was with basic DASH playback, so I have left the DRM out of the links and examples so as to not confuse the issue.

I am using two example videos, which are described here. Both these DASH file sets were created using the AWS mediaconvert service and are served from an S3 bucket, and both source videos are h264 mp4's. Vid1 is a portion of a custom course video and uses QVBR (multi-pass) with a max bitrate of 600kbps, segment length of 8s (video hangs at 8 seconds), fragment length of 2s, GOP of 30 frames, 15fps (converted from a slightly different framerate). Vid2 was added to test with a more "standard" video (Big Buck Bunny) and serves to show that the same problem exists with a completely different type of video made with different settings; it uses CBR at 500kbps, segment length of 4s (video hangs at 4 seconds), fragments are 2s, GOP of 48, and 24fps (using the source fps) .....................................................................................

The following links demonstrate the vjs7.8.4 problem with the two different videos when played in IE11, Edge-Chromium, and MacOS Safari 13 (note that both of these play fine on Chrome and Firefox)

Vid1 (hangs at 8 seconds, ie, the end of its first segment): https://elearninglaunchpad.com/devel/dash-test-vjs7-vid1.html

Vid2 (hangs at 4 seconds, ie, the end of its first segment): https://elearninglaunchpad.com/devel/dash-test-vjs7-vid2.html .......................................................................................

The following links demonstrate that the same two DASH videos play fine if using vjs6.13.0 with its DASH plugins (ie, these work on IE11, Edge-Chromium, and MacOS Safari 13):

Vid1: https://elearninglaunchpad.com/devel/dash-test-vjs6-dashplug-vid1.html

Vid2: https://elearninglaunchpad.com/devel/dash-test-vjs6-dashplug-vid2.html

...........................................................................................

Please use "inspect source" when using the links above to see the very basic code used to setup the player.

...........................................................................................

So, the bottom line is that given these two very different DASH videos exhibit the exact same hang problem across IE11, Edge-Chromium, and Safari 13, and do so across multiple machines, I'm inclined to think there might be some sort of flaw in vjs 7.x with regard to DASH playback. The only common denominator for these DASH videos is that they were both produced from AWS mediaconvert (although with very different settings) -- I can provide the AWS job setting details if that would be helpful, but I mentioned the key settings in the video descriptions above.

So, as much as I would like to see vjs7.8.4 work with these DASH videos, I'm also wondering if vjs7.x is maintaining backwards compatibility with the dash plugins that were used with vjs6.x? As demonstrated in the above files and example links, vjs6 (with plugins) is able to handle these videos better than vjs7.x..... but I need some of the improvements in 7.8.4, so I really don't want to have to rely on vjs6.x if I can avoid it.

Also, as mentioned, I ultimately need to use Playready, which does work with vjs6.13.0 without hanging, but hangs in the same way with 7.8.4 as would be expected.

Thanks for any insights or assistance you can provide in resolving these issues.

[welcome[bot]]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can. To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[third774]

It looks like this is also reproducible using the Big Buck Bunny manifest from the dash reference player https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps.mpd

[third774]

It seems like Edge's native HLS support may have either been broken or removed. Using overrideNative: true shown below fixed the issue for me.

{
  html5: {
    hls: {
      overrideNative: true
    }
  }
}

[gkatsev]

Yeah, for some reason things are behaving differently when overrideNative is set or not. So, for now the workaround is to set overrideNative to true and we'll take a look at why that is.

[dar1]

Kevin - thanks for the tip on using overrideNative -- I have just done quick tests with this option set true, using vjs7.8.4, on Edge-Chromium, IE11, and Safari (the 3 problem browsers that were hanging after first segment), and the two DASH videos now seem to play OK on all 3 browsers (I can't speak for Edge-legacy as I don't have it available). A few questions about this: 1) What is the common thread across these three browsers that would cause them to all be "fixed" with this HLS override? ie, it's a bigger problem it seems then just something that's gone bad with Edge. 2) I did not think that "HLS" overrides would help with DASH, but obviously it does help --- so DASH capability is affected by hls settings? 3) I've seen documentation indicating that if overrideNative is set, then nativeAudioTracks and nativeVideoTracks need to be also set false --- is that still true? 4) Would it be recommended to leave overrideNative set true across all browsers, including Chrome and FF, or is there any downside to doing so? 5) Since this override appears to be necessary for DASH playback in three prominent browsers, should it not be included or highlighted as a recommended setting in the docs/basic examples for people seeking cross-browser compatibility?

[gkatsev]

• What is the common thread across these three browsers that would cause them to all be "fixed" with this HLS override? ie, it's a bigger problem it seems then just something that's gone bad with Edge.

That is something we'll need to investigate.

• I did not think that "HLS" overrides would help with DASH, but obviously it does help --- so DASH capability is affected by hls settings?

the hls option is really for our playback engine. It used to be HLS only and thus the name was hls. We're in the process of deprecating that in favor of the name of the playback engine vhs to reduce this confusion as we can play back DASH now as well.

• I've seen documentation indicating that if overrideNative is set, then nativeAudioTracks and nativeVideoTracks need to be also set false --- is that still true?

That's also something that we need to re-confirm.

• Would it be recommended to leave overrideNative set true across all browsers, including Chrome and FF, or is there any downside to doing so?

I would recommend against setting it when playing back HLS content on Safari, otherwise, there isn't really any downside and in fact recommended. (We tried changing the default in an upcoming version of the playback engine but clearly there's something that's missing there too).

• Since this override appears to be necessary for DASH playback in three prominent browsers, should it not be included or highlighted as a recommended setting in the docs/basic examples for people seeking cross-browser compatibility?

Theoretically, setting override native for DASH playback shouldn't have been necessary at all. We'll need to investigate why it's not working right unles it is set.

[dar1]

Thanks Gary -- I'm new to this "issues" closure process for videojs, but I'm glad to see this problem is now recognized and will be addressed. I will remain available to follow up on evaluating any further fixes or for any questions that arise pertinent to my experience with this issue.

[gkatsev]

It can stay open until we investigate and fix the issue.

[shirt-dev]

I think this may be connected to https://github.com/videojs/http-streaming/issues/865.

[sushraja-msft]

I work on the Edge Browser team, we dug into this a bit and here is what we found.

This behavior was regressed in Edge - Chromium 84.0.486.0, because we started to expose audioTracks property on playing media elements (similar to Safari). In Chrome audioTracks always returns undefined, exposing the AudioTrackList seems to break video.js player.

You can side by side test this by starting edge with command line flags --disable-blink-features=AudioVideoTracks (no repro) or --enable-blink-features=AudioVideoTracks (repros).

I hope video.js can confirm this root cause and let us know why exposing audioTracks breaks the player, we are looking at mitigations on our end as well. Thank you, dar1 for the detailed bug report and test cases.

[gkatsev]

We probably want to default nativeAudioTracks false in all cases we default overrideNative to true.

[dar1]

Just checking in as the originator for this issue... Wondering what the outlook is for developing a solution for this? It would seem that having reliable DASH playback across browsers without the need for the aforementioned override workaround would be a fairly mainstream concern.

[gkatsev]

It's something that we should look into, however, the workaround should not be a cause for alarm.

[gkatsev]

I've re-prioritized this internally, though, may still take a bit to get out as we have a lot of other issues we need to tackle as well.

[vsalema]

solution https://codepen.io/vsalema/pen/xxJxWxQ

[lothar-cell]

Any progress on this?

UPDATE: Actually, I ticked WebRTC H256 codec in Develop/Experimental Features, and DASH seems to work now.

[rickykresslein]

@lothar-cell Unfortunately, ticking H265 did not work for me.

[lothar-cell]

To be fair, I gave up on YT frontends entirely, there's only trouble with them, like all the time. I'm using ImprovedTube now to customise YT : https://github.com/code-charity/youtube