Streaming == Content Protection? (Part 1)

Recently I got a chance to talk to a customer who does a lot of media streaming as well as progressive download. One thing he mentioned was that more and more people start to believe that if they want content protection, they need to switch to streaming instead of using progressive download from a web server. I know that this idea has been floating around for quite some time but I never imagined that content protection would be a major reason why people want to do streaming. Because technically they're just two different things.

The fundamental difference between streaming and progressive download is the protocol which defines how client controls the media as well as how media data is packaged on the wire. For progressive download from a web server, standard HTTP protocol is used and the binary format on the wire is the same as the file format. For streaming protocols, like RTSP/RTP, media specific control commands (like pause, seek, fast forward and rewind) are defined. Also when transferring the content, the original media file is broken into meaningful pieces (like headers, streams and samples) and repackaged into streaming protocol format. So in streaming case, the binary format on the wire is not the same as file format. This repackaging, however, does NOT alter the actual media data in any way. All the samples and header information stay the same. No encryption is involved. All the data is till in clear. It's sort of like converting your old word .doc file to the new .docx format. Yes, the format did change but whatever the original document has is still there in the new format.

Content protection typically happens at different layers. I usually categorize content protection into two categories: link protection and file protection. Link protection is for, as the name suggests, protecting the link. In another word, it prevents third-party application or entity that sniffs or hijacks the content transfer session. An example of link protection would be SSL. The payload is encrypted before getting transferred through the link and decrypted as soon as it reaches the destination. Link protection is usually associated with the transfer session, not the actual content or file. Because link protection is only protecting the link, it does not have any control over how the media file is used once it reaches the client machine. If you want to have control over the media file itself, you would then need a file protection mechanism. DRM is an good example of media file protection. For DRM content, the media data (usually samples) is already encrypted when the file was originally created. Web server or even streaming server can be agnostic about the media encryption. Because all they need to do is to deliver bits or samples. Whether the content is encrypted or not does not really matter. Decryption for DRM content happens when the user tries to view the content. Client machine needs to contact license server to get the license and decrypt the content.

So as you can see, content protection is not tied to streaming. Yes, you can do streaming with SSL or DRM content. But you could also do progressive download with SSL or DRM content. Streaming gives you more functionality for transferring and viewing the media content by using more specialized protocol, but from network delivery's perspective, it's just another kind of pipe. Content protection is a special sauce that can be added separately and optionally to both streaming or progressive download.

Ok, this is all about theoretical analysis. Next time in part 2, I will go into the details about the claims that some company are making about "Streaming == Content Protection". You feedback is always appreciated.

-Sam

7 Comments

  • Hi Sam, I think people link streaming with content protection because is not so easy to save streaming as in progressive download, where a simple "save target as" download and save the file to the hard disk.

  • Hi Ricardo, thanks for your comments. Yes, it is a lot easier to save media files from a web server today. My point is that even in streaming case there's nothing preventing a "full featured" streaming client to save the content either. All it needs to do is to re-assemble the pieces from the streaming formats back to the file format. In my view, the reason why this kind of tool is not so easy to find today is just because of the fact that most video sites are still using progessive download. If there's a day when streaming becomes really popular on the web, I bet downloading streaming content is just going to be as easy as downloading web contents today. Actually tools that can do download with streaming protocols (even proprietary ones) like MMS or RTSP have been around for a long time. Streaming is not a content protection mechanism in any way. Thanks again for your feedback.

  • Hi Sam, I agree with you. Although saving streaming media is not so easy, that does not mean it is impossible. As you said, there're some tools that can download streaming formats for some time, but I think most people don't know them, so they think it is more secure than progressive download. It's a false security sensation.

  • Question regarding the above. How would DRM on progressive downloads function? If content has DRM, the user needing to go to the licence server to buy and decrypt the content, would this work for progressive downloading? - ie if the content was purchased before the content is downloaded, would the content be able to play as it was progressively downloading?

  • DRM contents are encrypted and can't be played back without being decrypted which requires the license. So users can download and share DRM contents in any way they want. But once they want to play it, they need to go the license server to get a license. That's where the business logic kicks in.

  • Ok thanks, I understand the business logic, however if a customer were to purchase the licence before viewing the material, would the 'progressive download' be able to play from the start (if Meta tags were located at the start of the media file)? or would the new customer have to wait until the entire file, or partial file is downloaded??

  • Yes, as long as the header is located at the beginning of the file, which is the case for most download-friendly formats (like WMV/WMA, RM, FLV, MP4 with HTTP download optimization), client can play from the start as soon as the header and some amount of media data (typicall a few seconds worth of data) has been downloaded. Here is a typical sequence of actions:

    1) Client start downloading the file.
    2) Client finished download the header, finds out DRM license information.
    3) Client starts accquiring the license. Client could still keep downloading the file in parallel.
    4) After the license is accquired, with a few seconds of data, client can start playing.

Comments have been disabled for this content.