Support HLS through src= on iOS #997
Comments
joeyparrish
added
type: enhancement
|
Is the support for |
|
Will there be support for Fairplay on iOS with Key System "com.apple.fps.1_0"? This is probably related to #382 |
|
@chrisfillmore, no, it will be much the same. The difference is that desktop Safari has MediaSource, so desktop Safari will be able to play HLS through either mechanism. @avelad, hopefully this simplifies FairPlay for both iOS and desktop Safari. |
|
I'd like to offer a dissenting opinion. I invite others to chime in if they disagree, particularly if this enhancement would add value for them. A few months ago we attempted an integration with another vendor's HTML5 player, and decided to drop it after several weeks of work. One aspect of this player which was unappealing was how it attempted to be a universal solution for all use cases. We were looking to solve a particular problem, and were burdened with solutions to problems we didn't have. Something that is appealing about Shaka is how it is relatively lightweight. It solves the particular difficult problem of adaptive streaming. Setting If support for |
|
@chrisfillmore, thank you for your feedback. I will try to solicit broader feedback from the community before proceeding. |
|
We (happily) use Shaka player in our player and started recently to support fmp4-HLS with it. We have a complete different player for iOS using native src though, notably due to the fact that video ads work differently on iOS (e.g. src needs to be changed on each ad break). However if you can crack FPS on iOS Safari we would be more than happy to test Shaka player on that aspect. |
Because of the lack of tests (tests are coming) we did not see that the buffering system was failing to find media source to check if it had buffered to the end of the presentation. This change adds the logic needed to know if it has buffered to the end for each type of loaded content. Issue #816 Issue #997 Change-Id: Ief9d4bdc94f3121f889a0efa24a8b3d78377bb9f
Create the src= load branches for the remaining public methods. This should ensure that it is now safe to call the public methods when playing src= content and expect to get the intended return values. The tests to verify this are in a follow-up CL. Issue #816 Issue #997 Change-Id: I088b6bbd2489b3960457030846debae07fd86d16
This change moves the trick play logic out of the video wrapper so that it will be more available to the src= code. By doing this, I hope that we can make it clearer how we are working with the playback rate and ensure a tighter integration with it. Issue #816 Issue #997 Change-Id: Id462cda2c5eb82c3713237341424b91891bd38ea
Now iOS is supported for HLS through src=, so isBrowserSupported needs to reflect that. This makes MediaSource optional for any browser with src= playback of HLS. This also fixes probeSupport() to reflect the capabilities of non-MSE platforms such as iOS, which is critical for our demo app to be able to show the correct set of playable assets. Issue #997 Closes #1857 Change-Id: Ic6e18587db90fff2b097a2038c16cc928e2b9438
Without this attribute, iOS playbacks will force fullscreen mode. Issue #997 Change-Id: I32bbe3d16f68d91c5fb3083c5d5862967140d140
On iOS, for now, we do not have a list of tracks. In this case, hide the audio language menu. This also cleans up the hiding and showing of the captions menu, which no longer requires a special case for TS since we integrated transmuxing with the tracks API. Finally, this fixes a few minor indentation issues. Issue #997 Change-Id: I1b5bc329431e3d43a0238cd4af7839d220aa9b6b
The integration tests for src= failed almost universally on Tizen, but a few failed on other platforms, as well. The issue was the fixed delays in those tests. This replaces those fixed delays with an event-based utility that solved the same problem in other Player integration tests. Issue #816 Issue #997 Change-Id: Ib43cbb139ef77be1219e60d1fd5009aa403cc4cb
Instead of triggering src= based on 'video/mp4' MIME types, ask the browser what it can support using video.canPlayType(). Querying canPlayType() also allows us to detect src= support for native HLS in Safari. The original version of this change also added a complete fallback system to detect MIME types based on common file extensions and fetch MIME types via HEAD request when necessary, but the load graph system does not yet allow us to make async decisions about destination node. So this async MIME detection is commented out for now. Closes #816 (src= single file playback) Issue #997 (native HLS in Safari) Change-Id: If1930ca4fd5710481a925d63fb312d9a5b15fec8
Use a fudge factor to fix infinite buffering at the end of a native HLS playback. This could go away once we stop managing buffering state above the browser using playbackRate=0. Issue #997 Change-Id: Ib4a6fd5aa10dd84f9cfa4972d57db2cc63d7668d
Based on experimental evidence, this fudge factor has been increased from 50ms to 100ms. This is based on playback of the Art of Motion HLS clip from Bitcodin, where the 50ms fudge was insufficient. Without this, it goes into a buffering state at the end of the content. Issue #997 Change-Id: I7479705fd9e9359e70ab6ed3f24fd29dfdd7631e
Allow indirect access to members (such as DRM engine, manifest, etc) from Player methods as soon as they become available, instead of waiting until the very end of the load process. This fixes application access to several methods during the "manifestparsed" event. The point of the "manifestparsed" event was to allow early access to manifest and other metadata before streaming begins. This also lays the foundations for improvements in native HLS support in those same methods, including the ability to get track information. Issue #382 Issue #997 Fixes b/131604508 Change-Id: Ifee7b06fc2ccdcf5bcdf1c44f2f851d1d7e67fa1
It seems that once you start handling a request in the service worker, CORS restrictions are applied differently. So we shouldn't handle requests that aren't application resources to be cached. This cleans up the service worker and makes sure that we only handle the requests we are supposed to. This avoid CORS errors reported in a few old issues, as well as those seen in more recent Safari native HLS work. Issue #997 Closes #1256 Closes #1392 Change-Id: I0dff4a1f4f2a47b5f76a13625b673f717ebbd0ba
This is a generic implementation that doesn't rely on the audioTracks and videoTracks members currently only available on Safari. Issue #997 Change-Id: I849845513efb2ee51205dcdca8568c889f1f7cdb
This fixes the definition of load() to wait for a frame before resolving the load() Promise for src= playbacks. Now methods like isAudioOnly can be trusted as soon as load() resolves. This also allows load() to fail for src= playbacks if an error event fires from the media element. Issue #816 Issue #997 Change-Id: I0f6120d1334bbebcb78efdbbca65c7981f3ef265
Track methods are now implemented for native HLS and other src= playbacks. This will allow the UI to select text and audio languages. This change adds best-effort methods to get track information for src= playbacks, including native HLS on Safari. In many cases, it relies on the audioTracks and videoTracks members of HTMLVideoElement which are only implemented on Safari. They are in the spec, though, so there's no harm in using them when they exist. This is fully parallel to the manifest-based paradigm for MSE-based playbacks. Each of these top-level methods in Player has an "if" to decide which way to supply the requested info, except for the language methods, which now delegate to the track methods. With this, Safari's native HLS can supply audio and text language information to the UI/app, and the UI/app can have some control over those things through the tracks API. I believe this is important to the success of our new iOS support. Issue #997 Issue #382 Change-Id: Icc44a932927fafedda1b62a9d4c6e2ed3dc7db30
With native HLS, we have a better, more accurate, and more timely way to detect audio-only content. Use that whenever possible. This fixes the audio-only poster and PiP element state with native HLS content. Issue #997 Change-Id: Iee9f03deae6e56e7cfc140ed12278270eb667a41
Related to #816, we will be supporting HLS through Apple's built-in HLS implementation on iOS. This depends on the refactoring in #816, plus additional checks for Apple's built-in HLS implementation.
As in #816, using Apple's HLS implementation on iOS means most of Shaka Player's configuration will have no effect. The browser will be responsible for streaming, buffering, etc. Side-loaded captions would also fail (because we would not be streaming text, either). Shaka Player would only be able to control DRM and license requests.
But this does mean some playback on iOS with the same player you use on other browsers.
The text was updated successfully, but these errors were encountered: