Earlier this week, my Crapcast DVR decided that it didn't want to record the second episode of the Fox TV show "Fringe". I only realized this after Christine asked me if I'd deleted the episode.

After checking Fox's website, I realized that, in fact, the DVR failed to record the show. Before I could head to iTunes to download the episode, Fox's website seemed to have the show available for free.

After installing a plugin (Firefox calls it the MoveNetworks Quantum Media Player), within minutes I was downloading what appeared to be a near HD quality video stream of the full episode... without ads (well teasers/trailers seems like a small price to pay, but no ads inline, although when I just checked again, there do seem to be a few short ads interspersed)...

Warning: Geek content follows. For those not moderately interested in the mechanics behind this technology, suffice it to say, this is cool stuff, definitely check it out. The rest of this post will delve into the details of how it works.

I was skeptical of the video quality, but the approach that the MoveNetworks technology uses is ingenious. First, they split up the video into what they call "streamlets", or small "digestible" segments of video.

The advantages of this are multiple. First, if any network congestion or slowdowns are encountered by the client (which apparently has logic built in to determine if any frames are dropped), it can request the next streamlet of video at a slightly lower bitrate until the quality of the video matches the capacity of the network connection.

Secondly, this also means that there's very little buffering, and gives each viewer the best quality video that their connection can support at any given time.

Curious, I used tcpdump (for the nontech readers of this blog, this is a packet sniffer that allows the inspection of the data packets used for Internet communications) to identify what's happening underneath the covers.

The first question I wanted to know was whether they were using TCP or UDP. Typically streaming video uses UDP because it is generally a better protocol to use with applications which are time sensitive. In other words, if your connection gets really slow, there's no point in using a packet of data which contains video from 3 seconds ago. Video players that stutter back to 3 seconds ago once the data is obtained would be annoying. Much like Lucy should have done on the chocolate conveyor belt, let the ones go that are already on the floor, and focus on the ones coming down the line.

Interestingly, MoveNetworks uses TCP. With a "streamlet" strategy, they prefer to use the standard HTTP protocol (which uses TCP) which means they can use common web servers like Apache to keep their infrastructure costs low. (More on this in just a bit) Again, because their client has the intelligence to request smaller data packets when necessary, they intend to guarantee that the client only ask for data streams of "digestible size", to help guarantee that they drop very few frames of data.

Incidentally, this is a technique that TCP itself uses in negotiating window sizes. A window size, in the TCP protocol, is a negotiation technique that allows clients and servers to determine the ideal amount of data to be sent. Clients and servers that can handle larger and more packets gradually increase their carrying capacity until transmission failures occur, and then back off to about half that speed. The process continually repeats, providing, on what would on average appear to be 75% of the capacity of the network between the client and the server.

After what appears to be various tracking data being passed back to MoveNetworks, and some SSL traffic (secure traffic presumably intended to verify that the player requesting the data is an authorized player to help ensure that media pirates can't decode or fetch the streams), and a brief XML conversation, multiple HTTP streams are initiated at once to a content distribution network, or CDN. In this case, the CDN used is Limelight Networks, a competitor to the more widely known Akamai. (Note to the LimeLight security team-- you ought to suppress your server's response signature, as it's clear to anyone with a packet sniffer that you're using Apache/2.2.3.(CentOS))

All of this negotiation happens in a matter of 5 seconds or so. When the negotiation and authentication is complete, a standard HTTP request of "GET /qmplivefox/foxvod/ad/3ajn03/E575E001FD8 E254DB2E983A09D3B93F1_0400000003.qss HTTP/1.0" is requested from Limelight servers: "Host: move-od-405.vo.llnwd.net". The user agent is reported as "QSP.21:1[0].R{0-51698}". Interestingly enough, the portion of the user agent R{0-51698} is also requested as a standard HTTP content range header: "Range: bytes=0-51698".

As stated earlier, this is accompanied immediately by two other requests, this time with "Range: bytes=51699-10339" and "Range: bytes=103398-".

Generically, the responses tend to look like this (all standard HTTP stuff): "206 Partial Content", "Accept-Ranges: bytes", "Cache-Control: max-age=864000", "Content-Type: application/qss", "Age: 392446", "Date: Sun, 21 Sep 2008 04:33:06 GMT", "Last-Modified: Tue, 06 Nov 2007 03:41:11 GMT", "Expires: Fri, 26 Sep 2008 15:32:20 GMT", "Content-Range: bytes 0-51698/155097", "Content-Length: 51699", "Connection: close".

18ms later, the second response comes back with "Content-Range: bytes 51699-103397/155097", and 1ms after that, "Content-Range: bytes 103398-155096/155097".

Once these streams complete downloading, three new requests are made for 50KB of data each, this time for an incremented URI: "/qmplivefox/foxvod/ad/3ajn03/E575E001FD8E254DB2E983A09D3B93F1_0400000004.qss". It takes just 3 seconds to fetch another 150KB of data, so it would seem the initial packets establish a bitstream that is roughly 50KB/sec. (Compared to the H.264 codec, this bit rate would support a resolution of roughly 352x288@15.2 frames/sec)

Periodically, the https traffic continues to presumably update auth tokens to allow additional streams to be downloaded.

I didn't try to introduce network problems to see how the streams would be throttled back, but evidenced by decent video quality for nearly an hour, my broadband connection was able to sustain video quality that is of impressive quality.

Move has entered into agreements with other TV networks such as ABC and CW, which are also apparently using the Move technology. The client makes similar requests, "GET /vod/BBB87026/hss_113_finale_episode_1785344/A6B4B2BC1D05974993B831362BD5D9E4_0500000007.qss", although the traffic in this case goes to "stream.qec8.qcg1.qcn3.movenetworks.com" instead of to a CDN.

ABC shows a 1 minute ad you can't skip, unlike Fox, for each video "chapter". The ABC stream never got faster than "1623kbps" while watching Lost, and on the CW network, Supernatural never got past "730kbps" on my network. Traceroutes show that the ABC datacenter I'm using is in San Jose, and the CW network is also using the Limelight CDN.

These bitrates confirm my suspicion that the streams don't quite hit 720p HD quality, although they compare well to DVD quality.