EstablishedVideo in the browser
Ars Technica is reporting on Apple’s new proposal for a new HTTP video streaming standard. Its interesting that this comes so closely on the heals of the debate over the implementation of the <video> tag in the modern browsers. The issue in that debate, which I discussed recently, is that Firefox supports the Ogg Theora video codec due to its openness while Safari supports the h.264 codec due to its quality advantage and support from hardware decoders.
This streaming standard would be based upon an MPEG2 stream which could contain h.264 for video and AAC audio. This is an alternative to the existing standard Real Time Streaming Protocol (RTSP). RTSP needs its own server software and operates on a different port than HTTP. This means that it can easily end up blocked, purposefully or accidentally, from standard web traffic.
Content delivery networks (CDNs) like Akamai must also manage servers specifically for managing video that are separate from their HTTP caching servers. I dealt with this when I ran the web department at MGM Studios. We initially used Akamai and eventually moved to Limelight since Akamai is outrageously expensive. Regardless, at both vendors, HTTP caching is automatic after the initial set up but video files must be directly uploaded to the CDN’s servers (rather than the web host’s) and URLs must reflect that. This is just a complicated system overall. From my understanding, Apple’s proposal would allow content to be uploaded to the main web host then automatically cached by the CDN as if it was any other HTTP element. This would be an efficiency gain for site developers, lower cost for the CDN and be more reliable for end users.
There is a “but” however. The drawback is that HTTP delivery of video files would be in chunks. One long video would be divided up into parts as small as 10 seconds or so. While this would not be known to the end user, the video player would be consecutively playing parts of the overall video. This is great for bandwidth reasons. Servers would only deliver the necessary 10 second chunks, not the entire video. On the server side though, this would mean that a web video wouldn’t be a single file; it would be a file for every ten seconds of video. Suddenly managing files becomes a headache. Also, live video would operate on a ten second delay as each file is created and added to the stream.
Overall I think this is a good direction. It would be more efficient most of the way around and all it really needs is a way to manage video files encoded for it. It’s nice to see Apple proposing it as a standard and I hope that more vendors jump on the bandwagon.
I’m curious to see why Apple is making such serious moves for in-browser video improvements. Efficiency improvements are great but they impact big video sites the most. Apple delivers very little video compared to YouTube or Hulu. Why do I feel that somehow this is all tied to the future of the iPhone?