Exoplayer - HDCP test on Android
I first heard about ExoPlayer in an Android TV Overview presentation at Linaro Connect 2014, but I never really looked into it. The source code is available on Github, and I’ve been given ExoPlayer.apk as it can be used to test UHD H265 support, HDCP 1.x, HDCP 2.x compatibility, PlayReady & Widevine DRM using different format and so on.
ExoPlayer Demo – Click to Enlarge
So I installed it on Beelink GT1 Android TV box which I’m currently reviewing, and only include basic Widewine Level 3 DRM, and certainly does not support HDCP features.
There are 9 sections in the app to test various videos and DRM schemes:
- YouTube Dash
- Widevine Dash Policy Tests (GTS) – Widewine with or without HDCP, with or without secure video path
- Widevine HDCP Capabilities Tests – NoHDCP, HDCP 1.0, HDCP 1.1, HDCP 2.0, HDCP 2.1, HDCP 2.2, and HDCP no digital output
- Widevine Dash MP4, H264 – Various resolution (SD, HD, UHD) for clear or secure videos
- Widevine Dash WebM, VP9
- Widevine Dash MP4, H.265
- SmoothStreaming – Super speed or Super speed (PlayReady)
- HLS – Apple master playlist, Apple TS media playlist, Apple ID3 metadata, etc…
- Misc – Various video & audio formats and codecs (MKV, FLV, Google Play videos…)
I tested a few the tests without HDCP nor secure data requirement will work just fine. Widevine secure SD (MP4, H.265) would work fine, but as expect Widevine Secure HD and UHD would not work, and only show a black screen with audio since Level 1 DRM is not supported by my device.
Then I switched to Widewine HDCP 2.2, and to my surprise the video could play… I later found out that HDCP does not kick-in immediately, and if I play the video for a longer time, the video will stop after 9 seconds because Beelink did not get the HDCP 2.2 license for their box.
AFAIC, there’s automatic testing, and each test must be started manually. But it’s still a useful if you are interested in copy protection schemes supported by your Android device.
I’ll complete the post with something unrelated with ExiPlayer, but still interesting to check HDCP support if you own an Amlogic device, as there are some commands to check the status of HDCP:
- Show whether the TV is currently working with HDCP 2.x or HDCP 1.x:
| 1 2 | cat / sys / class / amhdmitx / amhdmitx0 / hdcp _mode 22 |
22 = HDCP2, 11 = HDCP1, off = HDCP not enabled right now
- Check HDCP authentication status:
| 1 2 | cat / sys / module / hdmitx20 / parameters / hdmi _authenticated 1 |
1=authenticated ok, 0 = failed to authenticate.
- HDCP keys for device
| 1 2 | cat / sys / class / amhdmitx / amhdmitx0 / hdcp _lstore 22 |
00 = no HDCP key, 14 = has HDCP1_key, 22 = has HDCP2_key
- Check TV HDCP version
| 1 2 | cat / sys / class / amhdmitx / amhdmitx0 / hdcp _ver 14 |
22 = TV supports HDCP2, 14 = TV supports HDCP1)
- Disable HDCP protection:
| 1 | echo "-1" & gt ; / sys / class / amhdmitx / amhdmitx0 / hdcp_mode |
------------------------------------------------------------------------cut line-------------------------------------------------------------
1. Choosing a Content Protection System(Clearkey,Widevine,HLS AES, PlayReady,FairPlay)
Content protection is key to a successful content monetization strategy for premium digital video publishers. When considering content protection, however, there is a delicate balance between strength of protection and the barriers it presents in reaching the viewers.
In addition to impacting user experience, there are direct and indirect technology costs, like additional development and maintenance of more complex workflows. On the flip side, more sophisticated systems can enable richer feature sets, such as offline viewing and TVE. All of these factors should be carefully considered before you commit to implementing a particular technology and workflow.
Besides DRM, there are several other options to mitigate the illicit distribution of your content. In this guide we will discuss three common approaches, including tokenization, encrypted streaming and DRM.
Tokenization
Tokenization offers a basic level of protection that can prevent most users from unauthorized viewing and sharing of content. This system works by creating a URL with a key or token that grants access, but has a short expiration period, preventing the use of that URL by other users once it has expired.
This system is simple and cheap to implement, doesn’t require any advanced software on users’ devices, and is supported almost universally. This is frequently used to implement content restrictions such as availability based on time, GeoBlocking, and IP restrictions.
Tokenization is limited in that it only protects access to the content. Once a motivated and technically proficient user gains access to the content, they are often able to capture that content using widely available tools.
Tokenization is typically implemented in conjunction with your CDN, and you should contact your CDN provider to get instructions on how to deploy this technology.
MPEG-CENC ClearKey and HLS AES Encryption
When content requires a higher degree of security, MPEG-CENC ClearKey and HLS AES Encryption, may be a good option. MPEG-CENC ClearKey is implemented as part of the Media Source Extensions (MSE) and Encrypted Media Extension (EME), which enable playback of protected content in web browsers. These content protection technologies protect the actual content themselves, scrambling the video with the AES-128 algorithm in either the CTR mode for DASH or the CBC mode for HLS (CTR and CBC modes are explained in more depth in the section on CMAF below). These systems offer several advantages over tokenization to protect your content. The first notable advantage is that encrypted content is unviewable without access to the decryption keys. Implementing an encryption does not carry any additional costs beyond its implementation, and in the case of HLS, can be implemented as sample-HLS, where only some parts of the video are encrypted, such as certain segments, rendering the video difficult or impossible to watch, but using fewer resources. These systems, however, lack the more secure key handling of DRM and do not offer some of the advanced license management or output controls that DRM systems enable.
See our tutorials for instructions on how to implement MPEG-CENC ClearKey and HLS AES Encryption.
Digital Rights Management
Digital Rights Management, or DRM, offer the highest degree of control over the viewability of your content. The most common DRM systems in the market today are: Google’s Widevine Modular (with some legacy implementations of Widevine Classic), Microsoft’s PlayReady, Apple’s FairPlay, and Adobe Primetime (a successor to Adobe Access, their flash-based DRM). Multi-DRM solution providers, like EZDRM, significantly simplify the complexities of implementing a Multi-DRM workflow to allow you to reach the broadest range of end-user devices.
DRM technologies differ from other content protection methods in a number of ways, including price, complexity, user experience, compatibility, and feature set. In addition to the cost of implementation, DRM systems also have a cost of use associated with them, usually on CPM-bases. Adding to the challenge is the fact that until recently, there was not a cross-platform protection standards, requiring a different DRM technology for each platform, as well, as creating and storing separate files to support each of the environments you may be trying to deliver to (See Appendix at the end of the post for an overview of DRM Support by Platform). Some technologies also offer richer features out-of-the-box, such as offline viewing, pre-provisioning licenses, or granular control over the outputs.
One of the main benefits of using DRM over other content protection technologies is the Selectable Output Control, which enables content providers to restrict playback to unauthorized devices. This is achieved with High-bandwidth Digital Content Protection (HDCP), a copy protection scheme that in theory eliminates the possibility of intercepting digital data midstream between the source and the display. However, it is a nuanced technology with many different versions for different implementations, adding one more layer of complexity to consider when selecting content protection technology.
Overview of DRM Technology Providers
Microsoft PlayReady
Microsoft’s PlayReady DRM is one of the most widely implemented DRM technologies, supporting MPEG-DASH with AES-128 in CTR mode (and recently CBC mode as discussed in the section below on CMAF) and Microsoft Smooth Streaming to web environments and many Smart TVs and web-enabled connected devices. PlayReady also offers sophisticated rights management, enabling the pre-distribution of licenses, rental windows that expire licenses after a certain timeframe after they are first accessed, and offline viewing capabilities, which can be particularly appealing to users who want to watch content on planes or other situations where they don’t have reliable access to broadband internet.
Google Widevine
Google’s Widevine system comes in two versions: Widevine Classic, and Widevine Modular. Widevine Classic has been End-of-Lifed by Google, meaning it will no longer receive new functionality. It requires a proprietary packaging format, and is rarely used outside of older Android devices (pre-4.4/Kitkat). It has little usage in the US, and is primarily seen in legacy devices in Asia.
Widevine Modular
Widevine Modular is Google’s successor to Widevine Classic. The Widevine Modular system is broadly supported today in Chrome web browsers and Android devices. Widevine Modular can be deployed on the web with MPEG-DASH with CENC, using the same renditions, encrypted with the same AES-128 in CTR mode, or CBC mode, and packaged in the same fragmented MP4 containers as Microsoft PlayReady, making them broadly compatible. The only difference in embedding process is the exchange of the keys made by a request to a different license server URL. There are no additional files that need to be stored on your origin to support this. Widevine also supports hardware security, which allows accelerated decryption, reducing CPU usage and enabling playback of Ultra High Definition content on devices that would otherwise be unable to do so.
Apple FairPlay
Apple’s choice of DRM technology is FairPlay. FairPlay provides many of the same advantages of other DRM offerings, and some additional degree of flexibility, but at the cost of a more complex implementation. FairPlay is only supported in Apple products, requires a direct relationship with Apple as a registered developer, and can only be used for streaming HLS video. FairPlay uses the AES-128 encryption algorithm in CBC mode, either in MPEG2 Transport Stream, or more recently, fragmented MP4 containers. This use of CBC mode has previously required either JIT encryption or a separate set of files on your storage to enable as they are incompatible with files encrypted with CTR mode. FairPlay also does not provide any of the advanced rights management that other technologies do out-of-the-box, such as licensing windows and offline capabilities, and functions for this must be built by your development team.
Legacy Systems
DRM has been around for some time, and as a result, there are legacy systems in the market that initially enabled these workflows, but have become deprecated and will soon disappear from the limited places that still use them. The most notable of these technologies are Microsoft’s Silverlight, which combined PlayReady and Smooth Streaming in a browser plugin to enable web playback, and was previously made popular by Netflix as their web DRM of choice. Adobe Access, implemented in Flash was another common legacy DRM system that has nearly disappeared from the market.
Open Systems
Open system, primarily in the form of HTML5 Media Source Extensions (MSE) and Encrypted Media Extensions (EME), are winning. Users, wary of malware, mandatory updates, bugs and security holes, are unwilling to install proprietary software and browser extension to support the playback of secured content. The adoption of fragmented MP4 and MPEG-DASH for playback by both Microsoft and Google means that these workflows can be significantly simplified, and users can access your content on their device of choice, without requiring replication of efforts to support them. The further support of CMAF conventions, Apple’s plan to support fragmented MP4, continues to reduce the need for replication in these workflows.
Implementing a DRM Workflow
DRM encryption may be implemented during two points in the workflow – during the encoding and packaging process or dynamically, just-in-time (JIT). JIT DRM advantages include added security with key rotation (e.g. rotating keys weekly or daily) and bandwidth savings, since you only need to keep one set of renditions on your storage. However, this approach adds complexity to the system, presenting another opportunity for failure, and leaves unencrypted files vulnerable to unauthorized access during transfer and storage. In addition, JIT encryption has ongoing costs associated with it, as the content must be encrypted again each time it is pulled. The advantages of JIT encryption will likely become irrelevant in the near future, as standardization reduces the need for the replication of files.
Bitmovin’s preferred method for implementing DRM is on the encode side. For details, please see our tutorials on setting up Google Widevine, Microsoft PlayReady, Apple FairPlay, and Multi-DRM systems.
On the playback side, the DRM workflow is initiated with the user requesting playback of a particular item of content. This causes the player to make a request to the DRM License Server, which is typically a proxy server that then checks with your servers to validate the entitlements for a given user. Once that request is validated, the License Server will return a key, enabling playback within the parameters that the user has been authorized for.
Note about Testing DRM Workflows:
- When testing your implementation, a few things are handy to keep in mind: it is perilous to attempt to test DRM in a Virtual Machine. Though VMs make it easy to develop for multiple environments, they have mixed support for DRM, as DRM requires hardware-level validation. Some VMs support this, some do not, and ensuring that this is properly configured is very challenging.
- Another common mistake in testing a DRM workflow can also occur in the HDCP signal chain – many computers use monitors hooked up by DVI, which has less support for HDCP than HDMI, and may not be something you think of checking while testing.
Common Media Application Format (CMAF)
The last topic covered during the session was the Common Media Application Format, or CMAF, a new collection of standards that has the potential to reduce the resources and simplify the deployment of multimedia and DRM protected content.
The CMAF standard, which was initially brought about as a collaboration between Apple and Microsoft, specifies several technologies required to deliver content to users. The most notable of these for this discussion is the use of ISO fragmented MP4, or fMP4 container, which has separate boxes for each of the video and audio fragments, which can then be called from the manifest using byte-ranges or stored as separate segments. Apple announced support for fMP4 at WWDC 2016. Though they still require the use of HLS .m3u8 manifests to address these segments, a separate manifest has a much smaller storage footprint than a separate set of video files.
Another good news for distributors of DRM protected content has to do with the mode of encryption. Apple’s FairPlay DRM technology leverages AES-128 with the Cipher Block Chaining (CBC) mode of encryption, where the Initialization Vector, a variable used in the computation of the encrypted output, is generated from the previously encrypted data. Google’s and Microsoft’s implementations of AES-128 in their DRM systems, use Counter (CTR) mode, in which a non-repeating variable is used for this purpose. Recently though, Google has added support for CBC in Widevine, and Microsoft announced in April 2017 that they are adding support for CBC mode to PlayReady encrypted content. While the end result of this has yet to be seen in practice, we may very well be able to implement DRM with a single set of media files (though still two manifests) in the near future!
Conclusion
Content protection, especially DRM, is a highly complicated subject, with many aspects to consider from business and technical perspective, including cost, complexity, user experience, and of course, protection of the content. Recent developments in file format and encryption standards give something to be hopeful for: a prospect of a simplified and cost effective workflow to deliver protected content! Bitmovin maintains integrations with all major multi-DRM solution providers for easy and reliable implementation of premium content protection for publishers.
Test it out with a free trial account!
Appendix
DRM Support by Platform
Web Browsers
Mobile Platforms
OTT Streaming Devices
Connected TVs and Gaming Consoles
更多相关文章
- 代码中设置drawableleft
- android 3.0 隐藏 系统标题栏
- Android开发中activity切换动画的实现
- Android(安卓)学习 笔记_05. 文件下载
- Android中直播视频技术探究之—摄像头Camera视频源数据采集解析
- 技术博客汇总
- android 2.3 wifi （一）
- AndRoid Notification的清空和修改
- Android中的Chronometer