Turns out that some aspects of video for iOS devices and the like takes us back to the early days of video on the web. These days, for those of us into video blogging and the like, we pretty much just upload and embed video and deliver it via HTTP. There’s enough processor power, bandwidth and the like to do this without too much fuss. Indeed, some compress to crazy bandwidth polluting specifications, but it pretty much still gets pumped around the interweb OK. (Bandwidth excess is pollution, it is the digital equivalent of having cheap oil so building cars that burn lots of fuel because it is cheap, and then spending billions on infrastructure for all those cars, but public transport, the environment, all sort of take a back seat.)
However, in the early days, when bandwidth was narrow, video was small, and not many of us actually played with it online, QuickTime had this thing called a reference movie (which was not the same as the reference movie option you get when saving a QuickTime file in QuickTime) which was a tiny little place holder video you created. This movie (which you made with the MakeRefMovieX utility) contains links to different versions of your QuickTime file. You embedded the ref movie in your page and the QuickTime plugin had a conversation, worked out bandwidth, and served up the appropriate version of the file.
Now, this was sort of clever and cool, as it meant that bandwidth appropriate stuff could be sent. But it turned out that in practice it wasn’t that great, for the very simple reason that it removed choice for users. Let’s say you have a big file of the finish of the 2009 World Road Race championships. Nice quality. But it is big. Real big. You also have a middle sized and small versions, and you’ve made ref movie so this is solved for me, the user. I’m on not great bandwidth, so it sends me the middle sized one. Yeah, ok, but I really want the big one. I know it will take 4 hours to download, but I’m a fan and for this content, 4 hours is fine. I want the hi-rez. A ref movie prevents me from choosing this. So what we did pretty quickly was simply compress our 3 versions and provide links to all three, with some indication of dimension and data size.
Well, as I’ve been catching up on the world of online video recently it seems we may be heading back to this older ref movie model. There have been some developments that I’ve missed, the main of which is HTTP Live Streaming. This is sort of like RTSP but via HTTP. It is an Apple developed protocol. The advantages are that RTSP uses funny port numbers and all that, so firewalls, proxies can all get cranky, which just means the content won’t appear. But if you deliver via HTTP, well, that’s the protocol and port (number 80 if you’re interested) that the Web uses, and there is no firewall that simply just stops traffic on port 80. It also turns out that the Adobe Flash Media Server, which I assume is Adobe’s version of video streaming (but unlike Apple’s Darwin server costs somewhere around USD4500 – heck the paid version of Apple’s OSX server which includes the video server is only $52.00!) also provides for this protocol largely because it is how you get video onto iOS devices.
This is going back to the future because a series of steps and constraints have been reintroduced:
- if you want to send video or audio that is over 10 minutes in length over a mobile network (NOT WIFI) to an iOS device then you just have to use HTTP live streaming (this is the overview page)
- If that isn’t enough then you must include a low bit rate version with a max data rate of 64 Kbps that it can default to when you hit that service shadow
- you need to run your compressed video through some other tools to get it ready for Live Streaming – this includes the Media Stream Segmenter, the Media File Segmenter, and the Media Stream Validator
- But it is ambiguous in the documentation if you have to do this, or it is recommended – essentially the protocol lets the client jump from different versions as it plays. This matters because the client may walk out of wifi and into mobile coverage while watching the content (as an example)
Given all this, I reckon for the project at this point we see how the RTSP example works, and we do a test over wifi for iOS, and we use that as the spec…. (WiFi delivery, not mobile telephony, to iOS devices).
UPDATE: saw mention that RTSP is just plain not supported on iOS, and that the requirement that HTTP live streaming must be used is enforced through the app approval process, so presumably if you just progressively downloaded the material it will still work, though the user experience could suck.