Safari 17 brings MSE to iOS about rx-player HOT 10 OPEN

Hello,

Ah yes I've heard of it but didn't perform tests with it, thanks!
If backward compatible, we could just perform the modifications you've done as a first solution, then maybe having some kind of abstraction layer in the future to better handle ManagedMediaSource's specific events.

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 (audio/mp4;codecs="mp4a.40.2", through here ManagedMediaSource.isTypeSupported) they don't like?

You could try calling:

ManagedMediaSource.isTypeSupported(`audio/mp4;codecs="mp4a.40.2"`);

in a console or standalone page and see if it returns true.

For the webm stream that's weird. I would guess the "sourceopen" (https://w3c.github.io/media-source/#dfn-sourceopen) event is not sent here? I don't know what would trigger it through a ManagedMediaSource and why it would be different than for a regular MediaSource... Maybe you're not supposed to attach a MediaSource to an HTMLMediaElement through an object URL created through the URL.createObjectURL API?

I'll have to look at Apple doc and examples if they exist.

from rx-player.

macOS reports true and iOS false for audio/mp4;codecs="mp4a.40.2". So perhaps ManagedMediaSource is not to blame there.

For webm, which should work, you're right about sourceopen not being called.

from rx-player.

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).
Maybe we could test a subset of that page to see if it works.

from rx-player.

Hello @alexg-axis,

We have made some tests on Safari 17 using ManagedMediaSource instead of MediaSource and it seems to work fine.

In this article Apple explain some details:

When designing Managed MSE, we wanted to make sure that nothing was left out by accident and that users continue to get the same level of features as they did in the past. So to activate Managed MSE on Mac, iPad, and iPhone, your player must provide an AirPlay source alternative. You can still have access to Managed MSE without it, but you must explicitly disable AirPlay by calling disableRemotePlayback on your media element from the Remote Playback API

Have you disabled the remote playback ? Can you try to disable it and give us feedback ?

video.disableRemotePlayback = true;

from rx-player.

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 ManagedMediaSource at the bottom of the list of media source implementation and then documenting the behavior?

Again, thank you for your help. I'm excited by the near future of DASH on iOS.

from rx-player.

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.

from rx-player.

Apple has released iOS 17.1 and with it comes support for all the codecs one would expect

Oh nice, that was a big pain point we had when testing it and thinking of potential use cases.

What would be the way forward for getting this in rx-player?

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 ManagedMediaSource API is still under discussion (w3c/media-source#320, w3c/media-source#329) for its inclusion in a future MSE recommendation, we were waiting until this API is well-specified and more signal about its stability is given before including it in the RxPlayer.

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 disableRemotePlayback property to true or to let the application do it. Here also, the EME recommendation is still a "recommendation draft" anyway (https://www.w3.org/standards/history/remote-playback/) so we moved that subject for later.

from rx-player.

macOS reports true and iOS false for audio/mp4;codecs="mp4a.40.2". So perhaps ManagedMediaSource is not to blame there.

For webm, which should work, you're right about sourceopen not being called.

the inability to use mp4 in ManagedMediaSource should be fixed in iOS 17.1

from rx-player.

OK so we have to look at why it doesn't trigger there.

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 disableRemotePlayback attribute to your video element (e.g. video.disableRemotePlayback = true;

See source code of https://jyavenard.github.io/htmltests/tests/ManagedMediaSource/bipbop.html

from rx-player.

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.

no, changing the feature flag is not longer required, it's on by default from iOS 17.1

from rx-player.