2011-02-09 00:00:00 | Technology

HTTP adaptive streaming not ready for prime time

Dan Rayburn posted an article about a white paper that tested the effectiveness of HTTP adaptive streaming clients. I posted a comment, and I will repost it here:

HTTP adaptive streaming not ready for prime time

Adaptive streaming over HTTP claims four benefits:

  1. Multiple bit rate streaming. It’s not unique. RTSP Realvideo, MMS/RTSP Windows Media Streaming and RTMP Flash streaming have this feature as well. I agree that over HTTP it works better.
  2. Works better with Firewalls than true streaming. Not a valid argument because you can tunnel RTSP, MMS, RTMP over HTTP. The real problem are not firewalls but proxy servers and they tend to kill HTTP adaptive streams as well…
  3. CDNs don’t have to deploy streaming technologies, can just work with caches. Not true, I will explain below.
  4. Better network utilization for network owners. Completely untrue because multicast delivery and UDP unicast delivery are more efficient than HTTP adaptive because of the TCP overhead.

What most people don’t know is that there are some serious downsides to HTTP adaptive streaming:

  1. No session based log processing. A single view generates hundreds, thousands log entries without any correlation. This is a stupid design flaw for most HTTP adaptive streaming services. Caches don’t keep track of logs per view session. That really cripples the logging capabilities of HTTP streaming technologies. The proclaimed benefit of HTTP adaptive streaming is that you can build a streaming CDN with just caches. Maybe a poor man’s CDN, but a true CDN has to be able to really offer good reporting. And for that, you need sessions based logging on the server side, not client side. Session based server side logging is critical to CDNs and content owners. Adobe doesn’t have it. Microsoft doesn’t have it. Caches don’t do it. Apple didn’t think of it. Wowza Media Server is the only product I’ve seen that does do this in a nice way.
  2. Crippled HTTP implementation. So it’s HTTP but the full HTTP spec hasn’t been implemented in many clients. A simple feature like HTTP redirect isn’t supported in some clients, which can break dynamic CDN functionality.
  3. QoE, no QoS. HTTP adaptive is claimed to be perfect for OTT content. Premium OTT content is the best of the best: the open access to content of the Web, and the quality as you get from walled garden cable TV. HTTP adaptive streaming offers an improved Quality of Experience, but there’s no Quality of Service. True streaming servers do offer QoS and more importantly, can report about QoS per individual session. The QoS data is key to CDNs who want to offer better SLA’s to premium OTT customers. Can’t do that with HTTP adaptive… This is blocking for premium content owners.
  4. No concurrent CDN viewers reporting. Which is a blocking issue for many content owners.
  5. Scale automation is an issue with some HTTP adaptive streaming technologies. It works great if you build a small server farm and manually setup some live streams. It gets tougher when you need to deploy a larger, dynamic CDN with automated publishing points management, distribution and management. The usual true streaming services like Helix Server, WMS, QuickTime/Darwin, Icecast, Shoutcast, FMS, Wowza have less bugs and are easier to integrate and automate.

Of course caching based CDNs and caching vendors tell the market that it’s all going to be HTTP adaptive. Maybe. In the future. When these HTTP adaptive bit rate technologies become more mature. The feedback we are getting from the content owners is that they are very happy with their existing RTSP mobile, RTSP web, RTMP web streaming services and are not considering to switch over.

Content owners say that HTTP adaptive streaming is not ready for prime time.

Content owners are just adding HTTP adaptive to their mix of codecs, file formats and delivery technologies to support additional clients like iPads, etcetera. For content owners, it’s all about reach. In reality, HTTP adaptive streaming will not fully replace true streaming technologies. It’s added to the mix. True premium content needs true premium delivery and that means HTTP, RTSP, MMS and RTMP.

When I moderated a panel for last Content Delivery Summit in London, we discussed this topic with a panel from Adobe, Microsoft and Wowza and some other (HTTP adaptive) streaming technology vendors and they all agreed as well that it’s all about the mix of delivery technologies…

This research document concludes the same: “it is clear that the existing adaptive HTTP streaming players are still at their infancy“.