Support HLS with Widevine #2089
Comments
|
Changes to support this were added underneath |
|
Does this mean that even when you add support in ExoPlayer, it will only apply to Nougat and up? Without the changes to |
Yes, which is partly why we're not prioritising this work right now. Widevine would need to provide a standalone library for Android to get this working on older versions of Android, which they don't do currently. Note that even if they were to do this, it would likely only be L3 security, which may or may not be acceptable for your use case.
What you refer to as transmuxing must presumably include decryption. So the same answer as above applies; Widevine would need to provide a library for this to be supported. DASH/FMP4/CENC (in "cenc" mode) is the recommended approach for delivering protected content to Android devices. |
|
Understood. What if we're doing HLS with fMP4 instead of TS? Presumably the lower-level details are the same as DASH. |
|
Unfortunately Apple mandated use of the |
|
I have my own packager, which I can configure to generate HLS with fMP4/CENC (effectively, producing m3u8 playlists instead of MPD files). EDIT: encoder->packager. |
|
The work to support HLS/WV/CENC(cbcs scheme) and HLS/WV/CENC(cenc scheme) is probably more or less the same, with some small caveat around propagating the right scheme information. However this work is not a priority for us at the moment because the standard compliant cbcs scheme is only going to work from Nougat. More generally, why would HLS/WV/CENC(cenc scheme) be a sensible thing to do? Such streams presumably wont work on iOS devices. If the streams you're generating are for Android devices only, you should really just generate an MPD instead. Choosing to attempt HLS/WV/CENC(cenc scheme) is attempting to use a worse, less well supported and non-standard-compliant approach that's pretty much equivalent to DASH anyway; why would you not just use DASH at that point ;)? |
|
Does ExoPlayer support DASH CBCS on devices running API level 24 (i.e. Nougat) [nexus players ]? |
|
@sivarajendranaidu it doesn't yet (but this ticket tracks it). As you can see in @ojw28's comment, this is a low priority task -- specifically because it only applies to level 24 and up (1.2% of the market). |
This will allow supporting more encryption schemes. Including some that require more encryption data, like the encryption pattern. Issue:#1661 Issue:#1989 Issue:#2089 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=155481889
At the moment, only CENC-defined scheme types are known values. This will allow having more information about the encryption scheme through the format, which in turn will allow more informed decisions on format support. Issue:#1661 Issue:#1989 Issue:#2089 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=159538907
Issue:#1661 Issue:#1989 Issue:#2089 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=159553419
This will extend our CENC modes support to cbcs and cens. The change was not split into two different CLs due to lack of test content for default initialization vectors, aside from AES-CBCS encrypted ones. Issue:#1661 Issue:#1989 Issue:#2089 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=159810371
This CL also makes DefaultTrackSelector take it into account when RendererCapabilities sets it to unsupported. A following CL could add a DefaultTrackSelector parameter to force DRM "known support" for specific track types. Issue:#1661 Issue:#1989 Issue:#2089 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=161556467
|
I had a question similar to @noamtamim. I understand HLS+fMP4+CBCS+Widevine is supported in Nougat+ (i.e. Android 7.x & 8.x), however, what's the minimum Android + ExoPlayer version that will support HLS+fMP4+CENC(CTR)+Widevine? The 2.6.0 release notes (https://github.com/google/ExoPlayer/blob/dev-v2/RELEASENOTES.md) state HLS support was updated to include "Support for Widevine protected FMP4 variants", however the Supported Devices page does not list HLS+Widevine support at all (https://google.github.io/ExoPlayer/supported-devices.html). Furthermore, the Supported Formats page (https://google.github.io/ExoPlayer/supported-formats.html) states that Widevine is not supported in HLS but is planned for API 24+. So while the 2.6.0 release notes do not provide specific Android version support, they seem to contradict the Supported Devices and Formats pages. Can you shed more light on what's actually supported wrt HLS+Widevine (CENC vs. CBCS) in ExoPlayer 2.6.0? TIA. |
|
@ojw28 @AquilesCanta is this issue implemented? It's not marked closed, but as mentioned above, the release notes for 2.6.0 say "HLS: Support for Widevine protected FMP4 variants" -- presumably this is this ticket. I'm asking because we have now implemented HLS+fMP4+Widevine in our packager, and the test stream doesn't work on ExoPlayer (but does work on Shaka). |
|
It should work, yes. Would you kindly send us a link to dev.exoplayer@gmail.com? |
|
The test stream is using "regular" cenc, not cbcs. Should it work as well? |
|
I checked and there was a glitch in the test stream when I tested. It works now. |
|
Please don’t close this ticket without updating/syncing the docs and providing feedback: Can you shed more light on what's actually supported wrt HLS+Widevine (CENC vs. CBCS) in ExoPlayer 2.6.0? |
|
The supported formats page has been updated already. We'll expand the supported devices page shortly. |
|
Both pages are now updated. |
Since October, Chromecast supports HLS with Widevine. ExoPlayer should also support that profile.
Does this require transmuxing and/or a change to MediaDRM/MediaCrypto/MediaCodec?
The text was updated successfully, but these errors were encountered: