Paid access to streaming videos.

June 25, 2011 7:42 PM

What is the best way to deliver streaming videos to paying customers?

I need to stream videos (not live- but I'd rather not go with a download model) to customers who have paid either for the individual video, or a subscription of some sort.

I will probably use a CMS of some sort for the site- Joomla or Wordpress.

What's the best way to do this? I have plenty of experience with the CMS, but none with e-commerce or restricting access to media.

Do I embed the videos in pages, and restrict access to the pages? Or somehow some other mechanism?

Also, I've heard that Amazon's cloud service is great for hosting media files. Would it be simple to integrate videos from Amazon's cloud into such a system?

Any tips or starting points would be greatly appreciated.

Thanks!

posted by kraigory to Computers & Internet (3 answers total)

Best answer: Generally, I'd go about this by:

1. Install CMS (you seem to be pre-disposed towards Joomla and Wordpress, so I'm assuming you'll want to use one of those, I wouldn't, but that's because almost all my experience is with Drupal)
2. Configure your CMS to save files to S3 instead of the local file system (again, I'm not a Joomla/WordPress person, but for Drupal, I'd probably look at media_amazon for D7 to start, I'm sure your CMS has some sort of option for this)
3. Create content and restrict it to be access by a role, e.g., "subscriber"
4. Ensure new accounts are not put into this role by default
5. Install whatever commerce modules you need for your CMS (again, I don't know Joomla or WordPress, but I'd certainly use commerce for D7)
6. Configure the rules/triggers/workflow section of your site to automatically add those who purchase a subscription to the "subscriber" role and be sure to add a rule/trigger/workflow that will remove them from this role when done
Couple of things to think about:
• If accessing the premium content (let's assume a plain M4V file) doesn't go through your CMS and just goes straight through, then anyone can get to it, logged in or not (similar to how people used to be able to link to facebook photos directly and anyone could see them if they went directly to that URL, logged in or not)
• On the flip side, if one of your subscribers wants to give a non-subscribing friend some of your content, making sure that all content access goes through your site won't stop them, they will just have to download/reupload elsewhere
• If you choose to not have your content access go through your CMS (in Drupal lingo, that would be a private file as opposed to a public file, and I'm not sure private files would work with S3 exactly since downloading the file through your server from S3 means you pay for all your bandwidth twice and don't realize all the benefits of S3 or CloudFront, I'm sure your CMS has similar options), don't name them something predictable, because then it will be easy for everyone to steal your content
• It's in your best interest anyhow to make sure your CMS handles the requests
• Mounting S3 as a filesystem means you'll pay twice for all bandwidth and it was never meant to do this, what happens when the connection glitches and your file system gets a forced unprepared unmount?
• Recurring billing and PCI DSS compliance is not for amateurs

posted by Brian Puccio at 8:18 PM on June 25, 2011

Ugh, forgot to close me ol tag. Wish there was an edit function here.
posted by Brian Puccio at 8:18 PM on June 25, 2011

The route you take will depend on how badly you want to prevent people from being able to get the videos without paying. For example, this:

Do I embed the videos in pages, and restrict access to the pages?

...would work but since you're not actually protecting the asset (the actual .mp4/.flv file), someone who paid could extract the URL to that asset and give it so someone else who could just download it directly; they wouldn't need access to the embedding page. Maybe that's fine with you, because it's really simple to implement this solution and maybe it's not worth the hassle.

If you do want to prevent this, there are various steps you can take. You can require some kind of access key in order to access the asset URL; this could be a URL parameter or a cookie value. The asset would then be served by a script that first looks up that key in a list to make sure it's valid, and only then does a sendfile()/passthru() to serve the asset. You have to implement some kind of system where the valid keys are aged out, either by time, by number of downloads, or by IP address. Here you have to make tradeoffs based on customer feedback. For example if you let a key be valid only for one download then maybe the person starts to watch the video and then their browser locks up, and they restart and come back and can't view it again and you get a pissed off email saying they paid for something that they didn't receive. So maybe you make each key valid for 3 hours or 5 downloads, and keyed to the /24 of the original requesting IP.

Another approach is to make the URL to the asset something that's harder to download, such as rtmp:// or rtmpe:// instead of http://. The upside here is that it's harder to get the content because you have to resort to specialized tools like rtmpdump or stream recorder software. But the downside is that you can't serve this from a plain web server any more, you need a streaming media server of some kind like Adobe's Flash media server product. Sometimes just being rtmp:// is enough to thwart people from figuring out how to download the stream, but you can combine this with unique tokens or other access controls if you're paranoid. A lot of the big streaming companies like Ooyala or Brightcove send the actual rtmp:// url in a response packet that is encrypted with a symmetric cipher like blowfish, and the decryption key is embedded in the flash player. This means that someone snooping the net traffic can't find the rtmp:// url.

Clearly however no solution is going to be 100%. It will always be possible to use screen recording software and the like to capture and share a video, even if it's not practical to just download the stream in its original form.
posted by Rhomboid at 8:44 PM on June 25, 2011