Take the 2-minute tour ×

I'm looking to implement DRM in an iOS video player, but I'm not sure how to implement this. In order to implement video DRM (while still using Apple's hardware accelerated H264 decode), I need a way to feed the decrypted H264 stream into the standard iOS video playback APIs.

According to this question, it was not possible to implement 3rd party DRM in September 2010. There's a thread in the Apple Developer Forums that goes nowhere. However, as of today a number of 3rd party DRM libraries exist: Widevine, Irdeto (PDF), Marlin. They have clearly found some way to pass a custom stream to the media player in Apple approved apps.

I've found two leads. One is a suggestion to create a custom URL protocol, but people seem to have poor success using this with video. The other is to create a local HTTP server thread and provide the content by HTTP live streaming on inside the iDevice. I'd like to be very sure that Apple will approve before going that route.

So - what Apple approved APIs do 3rd party DRM implementations use to get decrypted video data into the video player?

Edit: the latest BBC iPlayer for iOS allows programmes to be downloaded for later viewing. Either they store the content in the clear, or they have cracked this problem.

share|improve this question
Regarding the HTTP live stream on I can tell you that it works and it is accepted by Apple. Commercial solutions such as Verimatrix use this approach. –  Angel García Olloqui Sep 26 '12 at 13:22
Thank you - I hadn't encountered Verimatrix before, and I'll add it to our list. –  Adrian Cox Sep 26 '12 at 13:55
add comment

2 Answers

You can begin decrypting the file into another file and playback that file as you decrypt. You'll need to let it buffer a few seconds worth of video, but it will work.

Additionally you'll need to make sure that the moov atom is BEFORE the mdat atom in the file, otherwise it won't work. (AVFoundation, for example, creates MP4s where the moov atom comes after the mdat atom, and so they would need to be modified to work)

share|improve this answer
Thanks - I control the encoding, so the internal order of the file should be straightforward. That leaves me with a couple of problems - whether I can handle attempts by the user to seek forward in the video, and what to do about the large decrypted file in the file system. I don't think iOS supports sparse files, so I'll probably need to split the video into chunks similar to HLS to make this manageable. –  Adrian Cox Sep 6 '12 at 13:55
Yeah I can't tell you what the right solution is in your case. For seeking you can probably use the stbl atom's sub atoms to work out where in the file you should be decrypting and then decrypt from there into a new file. I think to do this well will be an interesting exercise in abusing the MP4 container. You probably also want to avoid decrypting the whole thing at once too, but you can avoid that fairly easily by using multiple aassetreaders –  jgh Sep 6 '12 at 15:42
I think every answer is going to be a hack, and we've only just started considering the architecture for the Android version. I've been surprised by just how limited these mobile APIs are compared to DirectShow. –  Adrian Cox Sep 6 '12 at 15:56
If it were as easy as DirectShow where would the fun be? ;) –  jgh Sep 6 '12 at 17:04
add comment

A working solution is local http server. But the patent application was submitted by Authentec.


share|improve this answer
They're submitting a patent for that? Wow... –  jgh Apr 27 '13 at 6:05
add comment

Your Answer


