-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safari 17 brings MSE to iOS #1294
Comments
Hello, Ah yes I've heard of it but didn't perform tests with it, thanks! For the tears of steal example, that's weird, it's true that maybe mp4 containers are not supported? It would still be weird because now HLS streams allow some mp4-based containers, so I suppose IOS should already have support for those. Maybe it is the way it is signaled ( You could try calling: ManagedMediaSource.isTypeSupported(`audio/mp4;codecs="mp4a.40.2"`); in a console or standalone page and see if it returns For the webm stream that's weird. I would guess the I'll have to look at Apple doc and examples if they exist. |
macOS reports For |
OK so we have to look at why it doesn't trigger there. Strangely, Webkit's own tests seem to not expect anything else (https://github.com/WebKit/WebKit/blob/8d7fefde87632cff6a30871a6bd46a7c37cf1470/LayoutTests/media/media-source/media-managedmse.html#L34). |
Hello @alexg-axis, We have made some tests on Safari 17 using In this article Apple explain some details:
Have you disabled the remote playback ? Can you try to disable it and give us feedback ? video.disableRemotePlayback = true; |
Thank you for your help. I'm happy to report that it works with the WebM stream now! For others reading this it might be worth clarifying that currently you need to enable the Managed Media Source Extension feature flag on iOS in Safari's advanced settings. There's a flag for requiring an AirPlay source which is enabled by default, which sounds like why we need to disable remote playback. What would be the way forward for getting this in rx-player? As it currently requires the feature flag and disabling remote playback, it's rather obtrusive. But as DASH currently doesn't work at all on iOS, perhaps it is safe to simply include Again, thank you for your help. I'm excited by the near future of DASH on iOS. |
Apple has released iOS 17.1 and with it comes support for all the codecs one would expect. That is, WebM isn't the only working codec any more! I'm unsure if the feature flag is still required as I already had it on before upgrading. |
Oh nice, that was a big pain point we had when testing it and thinking of potential use cases.
We also thought about this and for now, as it is only under a feature flag (for the main use case for it) and as the specification for the We do think it will be interesting to include it and perhaps rely on its other features when it becomes an official and stable part of MSE though. We also wondered whether it was our role to manually set the |
the inability to use mp4 in ManagedMediaSource should be fixed in iOS 17.1 |
ManagedMediaSource in Safari requires that you either make it compatible with AirPlay (by adding a secondary source element with an AirPlay compatible stream: such as plain mp4, hls. Or to explicitly disable remote playback by adding the See source code of https://jyavenard.github.io/htmltests/tests/ManagedMediaSource/bipbop.html |
no, changing the feature flag is not longer required, it's on by default from iOS 17.1 |
resolved with #1562 |
Safari 17 on macOS and iOS brings a new
ManagedMediaSource
implementation that Apple claim is backwards compatible withMediaSource
. It does come with some nice features on its own, but more importantly, this should mean that we can finally get DASH working in-browser on iOS. In theory at least.I've tried to make use of this new feature in rx-player by simply modifying
src/compat/browser_compatibility_types.ts
.interface WindowsWithMediaSourceImplems extends Window { MediaSource? : typeof MediaSource; + ManagedMediaSource? : typeof MediaSource; MozMediaSource? : typeof MediaSource; WebKitMediaSource? : typeof MediaSource; MSMediaSource? : typeof MediaSource; }
const MediaSource_ : typeof MediaSource | undefined = win === undefined ? undefined : + !isNullOrUndefined(win.ManagedMediaSource) ? win.ManagedMediaSource : !isNullOrUndefined(win.MediaSource) ? win.MediaSource : !isNullOrUndefined(win.MozMediaSource) ? win.MozMediaSource : !isNullOrUndefined(win.WebKitMediaSource) ? win.WebKitMediaSource : win.MSMediaSource;
(Actually, I just set
MediaSource_
directly toManagedMediaSource
to ensure it was used on macOS when testing, even thoughMediaSource
was available).Unfortunately, this doesn't seem to work as intended. On macOS, nothing really happens.
macOS logs when loading the page
macOS logs when playing tears of steal
iOS logs when loading the page
On iOS, it seems that things are working as far as DASH is concerned, as we get as far as complaining about the media codec. If I try the other streams I get mostly the same story - the browser is complaining about the audio (mp4a.40.2). However, that format should actually be supported on iOS per https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html.
iOS logs when playing tears of steal
If I try to play the Google - Sintel webm only on iOS, which should also be supported, I get the following logs.
iOS logs when playing Sintel (webm)
What stands out to me here is that everything seems to be going fine, but nothing really happens after the manifest has been parsed.
Resources:
The text was updated successfully, but these errors were encountered: