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
Comments