Update README Alternative setup for 2026 browsers - #7844
Conversation
|
cc @karlhorky Re #7827 |
| if (video.canPlayType('application/vnd.apple.mpegurl')) { | ||
| if ( | ||
| video.canPlayType('application/vnd.apple.mpegurl') && | ||
| 'ManagedMediaSource' in window |
There was a problem hiding this comment.
I would suggest against adding this condition, since IIUC the recent Chrome regression is a temporary failure
older versions worked fine with native HLS streams, also with gzip-encoded .m3u8 playlists
so this would lead to future (fixed) versions of Chrome incorrectly using HLS.js instead of using the native HLS support
@tmathmeyer what do you think?
There was a problem hiding this comment.
I'd agree if that were the case, but just going through the hls.js demo samples, with Chrome native HLS, reveals some pretty serious issues with audio-only, alternate audio, subtitles, captions, and live/low-latency support.
It's wonderful that it works fine for your content. I think the alternative setup warning and suggestion being added is still appropriate for general use. You are free to customize it to your liking.
There was a problem hiding this comment.
Ok, I can see that point - I wasn't aware that Chrome native HLS compatibility still had so many problems
I wonder if it will be a goal of Chrome and other browsers to also eventually return true for 'ManagedMediaSource' in window as part of native HLS support. If that's the case, then this PR does indeed seem directionally correct
I'm assuming that you mean the demo streams at https://hlsjs.video-dev.org/demo/ ?
Would be great to get a page of all of those using the current alternative loading technique before this PR (or maybe even without HLS.js entirely), to show all of the broken behavior in Chrome and other browsers
There was a problem hiding this comment.
I wonder if it will be a goal of Chrome and other browsers to also eventually return true for 'ManagedMediaSource' in window as part of native HLS support.
Support of ManagedMediaSource and native HLS are mutually exclusive. Adding the former doesn't fix the latter. As of this writing, it gets the job done. If that changes, you might have to update your support checks, and I the README.
I'm assuming that you mean the demo…
Correct.
Would be great to get a page of all of those
Great suggestion. I’m not sure we’d accept such a contribution, as support for HLS outside of hls.js is out of scope for this project.
There was a problem hiding this comment.
Great suggestion. I’m not sure we’d accept such a contribution, as support for HLS outside of hls.js is out of scope for this project.
@robwalch ok I created a project / webpage called HLS Compatibility Tests which syncs the streams from the HLS.js demo page, with a simple <video> player:
- https://github.com/karlhorky/hls-compat-tests
- Deployed webpage: https://hls-compat-tests.vercel.app/
As your comment above mentions, I can see a few more streams that Chrome is unable to play completely.
For example, the Elephants Dream stream with alternate audio tracks doesn't play audio. And the Widevine stream does not play at all.
cc @tmathmeyer in case you're interested in a tester website showing more incompatible HLS streams in Chrome
|
cc @dylanjha for insight on browser HLS support detection |
2 participants
This PR will...
Update README "Alternative setup" to guard against unreliable native HLS.
Why is this Pull Request needed?
Browsers like Chrome 147 return "maybe" for
canPlayType('application/vnd.apple.mpegurl')but fail to play some HLS streams natively. Add
ManagedMediaSourcecheck to limit nativeplayback to recent Safari releases.
Resolves issues:
Closes #7827