This is more of a suggestion, but in using this plugin, I discovered that it does not support iOS, which from what I now know to be a lack of media extension support.
However, HLS itself is actually an iOS standard so I think many would assume that this would work on iOS.
Would it make sense to add fallback support or at least explicitly state that iOS is not supported in the docs? I think it would save people some trouble.
iOS would not be supported on iOS as there is not Media Source Extensions(MSE) support, but you can provide an HLS manifest (i.e. .m3u8 URL) directly to the
Thank you for your reply. I'm aware that you can set the an HLS stream on the source directly on the video element in iOS, however, the issue is that this plugin does not gracefully handle that scenario. This is problematic as most people using the plugin also need to support iOS devices and may not realize that their HLS implementation is not working properly. This was tricky to diagnose and fix so I imagine other people would have the same issue.
Ideally there would fallback support for iOS support which could be done with a config flag, or perhaps include a section in the docs that would explicitly highlight this gotcha and provide a fallback snippet.
I also encountered this problem, IOS can play m3u8 video? I'm Video Tags to direct SRC add xxx.m3u8 links, but didn't play in the IOS, how to how to write? Can help me post code
@luoqiyou iOS support HLS but only by setting directly on the source and not using this plugin.
@zshenker any thoughts on my last comment on adding a note so people don't get led astray?
The majority who use this library write their own wrapper to handle this situation. It would be terrific if this scenario were handled out of the box.
@jonascript the problem with this is, what would we do about all the features that hls.js provides that the native player doesn't?
Most all hls.js events won't trigger - they will be opaquely handled by the native player. Unfortunately you'll have to stop using them if you want "compatible mode" to work. You'd have to steer clear of the whole API, and if you can't use any of the hls.js API, are you really using hls.js?
I think a better solution would be to change README.md to include some iOS-compatible fallback code, such as:
var video = document.getElementById('video');
if(Hls.isSupported()) {
var hls = new Hls();
hls.loadSource('https://video-dev.github.io/streams/x36xhzz/x36xhzz.m3u8');
hls.attachMedia(video);
hls.on(Hls.Events.MANIFEST_PARSED,function() {
video.play();
});
} else if (video.canPlayType('application/vnd.apple.mpegurl')) {
video.src = 'https://video-dev.github.io/streams/x36xhzz/x36xhzz.m3u8';
video.addEventListener('canplay', function() {
video.play();
});
}
That way, when people copy/paste from the README like I did, they'll (usually) get free iOS support.
Apologies for the late reply. I think adding a note to readme would be great.
Most helpful comment
@jonascript the problem with this is, what would we do about all the features that
hls.jsprovides that the native player doesn't?Most all
hls.jsevents won't trigger - they will be opaquely handled by the native player. Unfortunately you'll have to stop using them if you want "compatible mode" to work. You'd have to steer clear of the whole API, and if you can't use any of thehls.jsAPI, are you really usinghls.js?I think a better solution would be to change README.md to include some iOS-compatible fallback code, such as:
That way, when people copy/paste from the README like I did, they'll (usually) get free iOS support.