Playing encrypted video

Question

What I want to do is next: We need to protect the video content(encrypt it) and be able to play it.

Tricky part is that we do not want to load everything into memory

Answer 1

There is a way for Windows using file virtualization. The idea is to create a pseudofile those content is encrypted and can be decrypted on demand. E.g. with the help of BoxedApp SDK you create a virtual file that it is based on IStream using BoxedAppSDK_CreateVirtualFileBasedOnIStream. Then you pass the path of the virtual file to a player (an external application, or media player activex). When the player needs next part of decrypted data, this request passes to IStream, and its implementation decrypts data and returns it back. Thus entire file is not decrypted entirely at any moment. Also there is a large step-by-step tutorial.

Answer 2

The best choice for this today is:

1. Use S3, CloudFront, MediaConvert
2. Convert MP4 into AES-128 bit encrypted HLS stream (using MediaConvert) using an encryption key (customer-managed is easier)
3. Stream it on your website using VideoJS or other video player that supports playing encrypted HLS streams

If you have WordPress, you could also use a commercial plugin that creates and plays encrypted videos.

Answer 3

Ok, this is how I did it. (Android)

Encrypted video is placed in sd-card. RC4 encrypted - so it can be converted on the fly while streaming. Then I created a local file server that runs on the device (as a service). The output stream does a little something extra before sending out data - it filters it through an RC4 decrypter before writing it out to the buffer. Then just point the media player to the url of the video (http://localhost:port/abc.3gp"). As a result, video from the sdcard remains secure - you cannot play it unless you have the key - which you should differ for each video for additional security.

Answer 4

Just about every widely used encryption algorithm works on blocks of sizes between 128 and 256 bits – and will happily decrypt only a few of these at a time, just fine for streaming. Check out, e.g., Crypto++ for a software library that has streaming interfaces. (I.e., you just open a file, put a decrypting filter around that, and then just continue pretty much like with any other file.)

Answer 5

Thank you all for the ansers. I am a guy who went through a lot of different approaches.

I wrote my own Videoplayer using openGL+FFMPEG that could play mp4 and decrypt each frame in the GPU using shaders. I also experimented with another possible solutions, such as streaming from a webserver using VLC. (VLC offers some kind of encryption/decryption when dealing with streams), and yada yada yada.

Also one solution was to use 4 mediaelements(WPF) and the actual video was virtually split into 4 areas and each area was rotated so the video was not viewable. Once you loaded the video into 4 mediaelements, you could map out which part you wanted to show and also rotate it back. But in all honesty, MediaElement is bad.

However I ended up exactly with what RomanR said. I built DirectShow graph using mp4splitter, ffdshow, videorenderer and I modified mp4splitter sourcefilter. The reading happens in BaseSplitter/AsyncReader.cpp (just modify SyncRead function) that mp4splitter uses.

If you would like to implement it yourself, just use MPC-HC project and modify the filters as you like. It took me some time to get around the DirectShow concept, but once you understand it, it becomes great weapon.

http://sourceforge.net/apps/trac/mpc-hc/

Answer 6

Playback pipeline is typically a set of components plugged in together. In DirectShow, one of the APIs and the most popular one, one uses reader, splitter, codecs, post-processing and presentation parts known as filters and the whole thing plays back. It is possible to substitute reader with your own replacement which reads encrypted content and decodes on the fly. It can easily be decoding on demand, no need to decode the whole 2GB block in order to for example get a first frame or a thumbnail.

Having only hooked the reader part you are free to choose encryption method, between custom algorithm, one one of well known, API or external library.

Still I think this and other (at least most of the other) ways do not get you bullet proof guarantee that encoded content cannot be reversed. Someone else can still hook into the pipeline and grab decoded content from there. If you are happy that this at least will require complexity and experience to implement, then such encryption is going to work out pretty well.