Regardless of how much of an "abomination" RTMP is, Apple's system is a huge hack:
1. It's taking a transport stream format based around a buffering model... but as far as I can tell, completely ignoring the actual buffering model itself. Instead of working within the MPEG buffering model, it simply makes some arbitrary restrictions on the size of each chunk, which doesn't make any sense.
2. Aggravated by 1), the latency of the system is horrible. Good luck using "HTTP live streaming" for anything that needs less than 5 seconds of latency, let alone 0.05 seconds.
I can implement a videoconferencing system in RTMP. I sure as heck can't do it with "HTTP live streaming".
Now, does it work well for some use-cases? Sure, but it's definitely not a replacement for all aspects of RTMP.
(Also, obviously as you mentioned the link is biased, but it's actually not even relevant to your post: it's comparing Adobe's software to Microsoft's software, not comparing protocols. Talking about Adobe's software is very silly when nearly everyone actually uses Red5, Wowza, etc. For example, it mentions that the latency is ~6 seconds, but the company I work for has that down to ~100 times less.)
Not a huge fan of HLS for our customers even with libraries of tens of thousands of full length movies serving to iOS. Latency is the number one complaint. Meanwhile, to your point, we churn out video broadcasting sites for clients on RTMP.
EDIT:(We support server side PPM on RTSP, RTMP, and both Apple and Microsoft adaptive HTTP, from WMS, IIS Media Services, Wowza, DSS, and FMS. This makes us pretty familiar with the buffering approaches, and agree with you, Apple's is essentially broken. That said, the value of being able to leverage a more "commodity" HTTP infrastructure is huge.)
Been meaning to talk to you some time about x264 in the near real time mode. Drop me contact info to my user name at gmail?
PS. We use both Red5 and Wowza, but usually Wowza for these kinds of projects, which we have deployed CDN-wide.
1. It's taking a transport stream format based around a buffering model... but as far as I can tell, completely ignoring the actual buffering model itself. Instead of working within the MPEG buffering model, it simply makes some arbitrary restrictions on the size of each chunk, which doesn't make any sense.
Yes, it totally ignores the MPEG buffering model. Perfectly valid streams don't play on Apple devices.
Why do you say RTMP is an abomination? (I feel like the comparison chart you linked to didn't make so strong a case -- are you speaking from experience with the technologies?)
RTMP is missing basic features for modern scalable distributed video delivery (video from more than one server), which is odd since it was actually late to the game.
Meanwhile, these newer HTTP streaming (not talking about progressive download or pseudo streaming) protocols let you leverage much more widely adopted and understood delivery platforms.
Hm, but why would you want a 302 at the perimeter? That sounds suspiciously like trying to solve a problem (loadbalancing?) at the wrong layer to me.
However, anything else?
I'm honestly curious, as until now I've been fairly ambivalent about RTMP and am a bit surprised about the flak it's getting. Especially with Apple's "oops we didn't know HTTP supports range requests"-hack being pitched as the alternative...
(edit: ah I see DarkShikari already set that one straight)
In a CDN environment, load balancing is a far more complex subject than can be entertained in this thread. Suffice to say that load balancing is not just about spreading requests evenly over machines, you have to make intelligent decisions. If the customer of the CDN is unwilling to lift a finger to do things differently when integrating with a CDN, you can have a problem. In the HTTP world, 302 redirects can work around that very efficiently, in certain cases.
As to what other problems RTMP has: 1) a significant amount of state and therefore RAM needs to be kept per connection 2) there is no standard URL format that describes where to separate the connect() string from the play() string 3) no standard way to specify query terms on the connect() string 4) it cannot be cached by nodes outside of the CDN 5) you are required to use Adobe's FMS if you need to use SWF verification or RTMPE which has significant other ramifications.
That's just what I can think of off the top of my head.
Yes I know, I'm running my own little Wowza cluster of a couple dozen hosts, so I have faced the same problems. ;-)
If the customer of the CDN is unwilling to lift a finger
Okay, I guess that's an argument - although I'm not sure to what degree this can be held against the protocol.
As for the other problems you mention (apart from the RAM issue), I can see how they can be problematic in a multi-tenant/CDN environment. I'm just not sure I'd want to see a transport-protocol packed with all those concerns, as that would result in a lot of bloat and half-baked trade-offs (i.e. quite possibly even worse than RTMP).
While some basic building blocks (e.g. the 302) would indeed be helpful, we have so far had good luck with encoding meta-data into the URLs (crypt/hmac) and handling the logic on the origin.
Anyways, thanks for the insight. It's always interesting to learn how other people use and look at these things.
Not sure if it is a factor but Wowza has supported HTTP Live Streaming for a while, maybe they've been eating at a bit of Flash Media Server's market share.
As far as I can tell, there are no Open Source streaming servers that support (realtime) HTTP Live Streaming. I think this is a massive shame and I would LOVE to see one.
So I think it makes great sense for Adobe to add support for this as there are so few HTTP Live Streaming solutions out there right now.
segmenter (various open source variations floating around googlecode, github and other places) does too, by creating the files and letting you stream them out with your own web server (Apache, nginx, ....)
Good. I would expect, and hope for, support for http streaming on Amazons CloudFront service soon since they use Adobe's media server already. [1] This would be really helpfully for some indie iOS developers.
I'm building a video post-production workflow system for a client in Hollywood currently so this kind of news is very welcomed. Anything that makes it easier to stream and/or gives me more choices and less compatibility issues is great.
Biased feature comparison: http://learn.iis.net/page.aspx/792/adaptive-streaming-compar...