PHDS is not related to higher education, but is a very powerful option to stream protected content to Flash and Adobe AIR clients. If you don’t have to protect your content, you properly don’t need to read any further – if you do, you should be aware of its functionality, and the benefits for your streaming deployment.
Flash/AIR content protection options
RTMPe
RTMPe is the most popular way to protect content. It’s very easy to turn on, simply switch your rtmp:// URL to rtmpe://, and your server will provide an encrypted streaming channel. In addition, you can lock down the SWF player with SWF verification to make sure only your player consumes the stream.
HDS (or RTMP/PD) with Flash Access
HDS in combination with Flash Access provides high-end content protection. Flash Access is not limited to HDS, and also works with progressive download, or RTMP streaming. The Flash Access setup in this case includes a license server, and provides all the robustness you need.
pRTMP
pRTMP, or protected RTMP, is a new generation of RTMP content protection.
Flash Media Server encrypts on-demand media files and embeds a Flash Access 3.0 license in the DRM metadata of the content. Flash Player and AIR clients communicate with Flash Media Server to play the media. Protected RTMP does not require a license server; the license is embedded in the content metadata and a client receives it along with the media.
Protected RTMP is more secure than RTMPE because it uses Flash Access 3.0 DRM content protection. Protected RTMP encrypts the content whereas RTMPE protects the communication channel. Because data is unencrypted, companies like comScore and Nielsen can measure protected RTMP video. (via Flash Media Server Developer Guide)
PHDS
PHDS is very similar to pRTMP, but based on HTTP Dynamic Streaming.
Use Flash Media Server 4.5 to serve live and on-demand protected content to Flash Player and AIR over HTTP without using a DRM License Server. When Flash Media Server packages the content, it generates the license and embeds it in the metadata of the content stream. This feature is called Protected HTTP Dynamic Streaming (PHDS). In addition to encrypting content, PHDS also supports SWF verification for HTTP Dynamic Streaming. (via Flash Media Server Developer Guide)
Guidelines
This might sound a bit confusing, therefore here is some guidance:
Best possible protection -> Flash Access (requires Flash Access license server)
Robust RTMP based content protection, better than RTMPe, without license server -> pRTMP
Robust content protection for HDS, without license server -> PHDS
Conclusion
Flash Access will always provide the best content protection, but for certain use cases, e.g. live streaming, it’s more important to have scalability by avoiding license server requests. That’s why it’s important to understand the characteristics and benefits of PHDS.
In case you need to target iOS from the same workflow, Flash Media Server also supports protected HTTP Live Streaming (PHLS).
The much larger problem with HLS is a legal one. Any software that decodes/unpacks/creates an M2TS file must pay a $0.25 royalty per application to MPEG-LA. This is steep because MPEG2 licensing was designed during the DVD playback era – not Internet streaming.
The only major platforms that cover this license fee for the developer (that I know of) are iOS, Mac OSX, and Windows (you can view all licensee info on the MPEG-LA site). And those licenses are only valid if the actually decoding is being done by the built-in decoders for that platform. That means any support for HLS playback in the Flash Player (decoding done via ActionScript) or on Android are not covered (As far as I can tell, Google does not pay this license for Android licensees and the only licensee that pays it is Samsung) and require $0.25 per end-user application to be paid to MPEG-LA. So every time a unique user watches an HLS stream in Flash Player the provider of that application is required to pay the royalty for that user – which would be astronomical. It’s probably just one time per user, per app, but I’m not a lawyer so I’d suggest you consult one for clarification if this matter interests you.
The fact that so many content providers either don’t know about this (irresponsible due diligence) or don’t care (irresponsible business people) bewilders me.
So, if your company has bet the farm on Apple’s HLS you’d better ask your legal team to make sure you’re clear. Otherwise use of streaming technologies that rely upon fMP4 are likely covered by the built-in decoders, which most platforms already have. Consult your legal counsel on that as well.
This is a dirty little secret, by the way. It’s why you see very few popular free and commercial video players (JWPlayer, for example) making a big deal out of their HLS support. The burden to pay the license is on the company that delivers the final app so the players aren’t directly responsible but they know that understanding this requirement would make the solution impractical so it’s not worth pursuing.
Apple understands this whole licensing problem. But it doesn’t affect them at all because they pay the royalties for the server and client. As long as you deliver HLS to an Apple client you’re good. Think about that for a minute…
If I were responsible for streaming media to anyone I would avoid HLS at all costs, other than doing a to M2TS from fMP4 on the server for actual iOS clients – which both Adobe’s FMS and Microsoft’s IIS Media Services provide for free. Plus all of the other reasons that Jens points out above.
Good read, btw, Jens. Thanks for writing this.
Livefyre posted this comment on the wrong post and I can’t move/delete it. It was supposed to be posted to your HLS vs HDS post.