Ah yes, Akamai as always picking features that maximize the money you owe them.
For the vast majority of content (e.g. anything not live), constant bitrate is a terrible idea: it wastes bandwidth in low-action parts of the video and cripples quality in high-action parts of the video. This is why no major non-live video site uses constant bitrate; it's a terrible idea.
Of course, if you want to maximize user quality at all times, you want to maximize utilization of their connection and adapt the bitrate to the bandwidth available. But in reality, bandwidth is expensive, so nobody does this except in live streams.
For those not familiar with Akamai's current product lineup, the new features they've introduced here are:
1) HTTP delivery of live flash content (avoids royalty fees normally paid to Adobe for FMS, so ideally Akamai could lower their prices)
2) Improved analytics (current EdgeControl interface is tricky to use for individual videos)
The rest of the features listed are just current features wrapped up into a nice looking press release. In other words... move along, nothing to see here.
Now consider the fact that the majority of websites are still using VP6 or Flash Media Encoder FLV, both of which are significantly worse than Xvid on the chart...
Of course, given that money doesn't grow on trees, many of the top players have switched--Youtube and Facebook are now using x264 almost exclusively, for example.
I would be entirely unsurprised if Akamai ended up being suckered by a company providing inferior solutions. Of course, they don't lose anything by providing worse compression, since their customers pay them for the bandwidth.
One of the biggest problems we've run into doing h264 streaming is that there are a huge number of users that don't have powerful enough computers to decode and view h264 in a flash player when it's delivered at 720p. You need a pretty fast system to watch 720p video at even 3 Mbps in the Flash player.
And h264 over HTTP is just a download of the HTTP file starting from a specific marker unless I'm mistaken. Not exactly rocket science. It's HTTP after all...you can't control much of anything on the QOS side. The JW player has the capability to do that out of the box for most of the major CDN networks out there already.
The Flash player has a horrifically inefficient H264 decoder. One is almost led to wonder, at times, if it's interpreted. (This would explain a lot.)
HTTP pseudostreaming is, indeed, just a plain HTTP GET with a URL parameter (or an extra header) to indicate what byte position to start at, based on a seek index at the front of the file. It's incredibly "dumb", but trivial to implement even on a shared web host. (You can write the server-side component in a few dozen lines of PHP, for instance.)
The Flash player has a horrifically inefficient H264 decoder. One is almost led to wonder, at times, if it's interpreted. (This would explain a lot.)
The reason it's slow is that the compositing engine requires that the YV12 -> RGB conversion be done in software rather than in a hardware overlay. This is probably exacerbated by the fact that many sites still seem to turn off the hardware accelerated display out. Note that as far as I know, all current implementations of HTML 5 video have a similar problem (compositing engine requires RGB input).
It's based on Mainconcept's decoder, which while not incredibly fast, isn't particularly slow either. Though I wouldn't be surprised if Adobe stripped out some of the assembly to try to make it smaller (or compiled it with -Os).
My advice for performance would be to disable CABAC; that can probably save 15-25% decoding time right off the bat at the cost of 10-25% compression.
Flash only supports hardware accelerated display when you're running full-screen in "kiosk" mode. That is not too useful.
What we've done is sacrifice some quality and encode using one of the mobile h264 profiles (I forget which profile off the top of my head). It essentially outputs h264 in a form that is easier to decode on the client side. It helped us eke out a few extra fps that helped quell an initial user revolt.
Most of the higher profile features of H.264 actually decrease CPU requirements at the same quality level, because they reduce bitrate required for a given quality (in particular, B-frames and 8x8dct).
The only things that significantly affect CPU usage are CABAC, deblocking, bitrate, and resolution. Sticking to a "mobile" profile (i.e. Baseline Profile) is needlessly slashing quality.
Pseudo streaming h264 is a bit trickier than a dozen lines of PHP, although that works for FLV files (I'm assuming you've got your h264 in a .MOV-like container here, since that's what's recommended). You'll need to create an updated file header with new offsets to samples, which is a bit more work than "add a FLV header and cat the rest of the file".
The good thing is that it's Been Done for most servers (mod_h264_streaming modules exist for practically everything under the sun), so one rarely has to reinvent the wheel.
> The flash demo jerked and jumped around in bandwidth a lot.
Not only that it was taking 90% of my CPU to display something that did not look even close to 720p in size. And how can they get away with calling that looks more like 360p HD, anyway? I am not impressed.
All the international footprint video delivery networks support 2 mbps streams, and Akamai is not the only one (not even the first) to support the various flavors of adaptive streaming, from Windows Media "MBR" to Silverlight's Smooth Streaming to Apple's adaptive HTTP. Akamai's just the first to take what's been working great on all these networks for months or years and say, "Oh, we could press release this and because we say so, everyone will think it's new and unique!"
Ah yes, Akamai as always picking features that maximize the money you owe them.
For the vast majority of content (e.g. anything not live), constant bitrate is a terrible idea: it wastes bandwidth in low-action parts of the video and cripples quality in high-action parts of the video. This is why no major non-live video site uses constant bitrate; it's a terrible idea.
Of course, if you want to maximize user quality at all times, you want to maximize utilization of their connection and adapt the bitrate to the bandwidth available. But in reality, bandwidth is expensive, so nobody does this except in live streams.