The basics of a “slow demand” video service

A “slow demand” service is when you are forced to make a decision, some time passes, and then you get whatever it is you picked from the menu of options.

Several years ago – call it 2004-ish – I spent a fleeting amount of time thinking about how to design a really good set top box that would facilitate a “slow demand” video service.  This was around the time that I had permitted four things to enter my life – Netflix’s DVD by mail service, O’Reilly’s Safari on-line bookshelf, a DirecTV Tivo set top box, and Freenet – and my idea was essentially a combination of these four services.  Here’s how it worked.

  • You have a queue service – like the Netflix queue – that lets you create an ordered list of things you might like to watch.
  • You have a set top box that – like the DirecTV Tivo – is actually two independent devices.  In that case it is a satellite receiver and a DVR.  In this case it will have small, encrypted storage device and a hardware security module that will manage a secure local locker of data that isn’t yours – like a Freenet cache.
  • That encrypted storage has slots – like the original Safari bookshelf – that permit you to have x number of items from your queue at a time.

The service works by charging you for the number of slots in the encrypted storage, then pre-populating those slots by popping off items from the queue and delivering them so that when you get home from work and want to watch a movie, that movie has already been downloaded to your set top box.  And, just like Safari, it stays there until you delete it so you can fill that slot with something else.

Ten years ago I probably would have used a traditional data moving protocol for the download (although I think I was already sour on FTP, so perhaps rsync), but I think if I built it today, I’d probably use a bittorrent-like protocol to send that file out to the set top box either using pure torrents (to benefit from network effects), or even just by creating a btsync folder for each subscriber in the data center that syncs to their set top box (for simplicity).

That’s it.

If you look at television and break it into two piles, as I do, you get the things that absolutely, positively must be streamed as linear programming because they are live and their value is fleeting.  For me this is just breaking news and sporting events, other people might have a different set of things, but there are really just those two buckets; live stream and download.  Streaming video programming that isn’t happening right now is just absurd, from an engineering perspective.

The HSM and disk encryption isn’t completely copy-proof if you aren’t using a secure link to the display, but it is pretty close and the system is easy and serviceable and you could put the whole thing on a PCIe card or USB peripheral or HDMI appliance, so the ease of use dis-incentivises most of the people who otherwise might want to pirate the content, which is probably a sufficient step to make the business work.  And because it isn’t trying to deliver in real-time using streaming the user experience is awesome even for BluRay/superHD and it is the Internet equivalent to “good for the environment”, particularly for people who aren’t home all day long but who have always-on Internet connections.

When I look at how today’s video services work, they all have the queue, and most of them have ecosystems that include appliances, but they haven’t taken the next step to actually pre-fetch items in the queue into appliances that can support a secure local locker.  That seems to me to be a big mistake given their peak traffic time conflicts with their last-mile providers.

In layman’s terms, that means that at 8 pm Eastern time when 27 million people sit down to watch an on-demand video (be it from Netflix, Hulu, Amazon, or somewhere else) the network of their ISP is flooded with streaming content – as well as Web surfing and video games – all of which has to compete for relatively limited resources, however the people who use a service like the one described above aren’t asking Verizon or AT&T or Comcast to deliver that content to them at 8 pm – because it was delivered earlier and is waiting in their device ready to be played.