Adobe Adopts HTTP Live Streaming For iOS 97
unassimilatible writes "Ars Technica reports that Adobe has capitulated in the iOS-Flash war, and has adopted HTTP live streaming for iOS. HTTP Live Streaming is a protocol that Apple developed to stream live and recorded video using standard HTTP connections instead of the more difficult to optimize RTSP. It uses H.264-encoded video and AAC or MP3 audio packaged into discrete chunks of an MPEG-2 transport stream, along with a .m3u playlist to catalog the files that make up the individual chunks of the stream. QuickTime on both Mac OS X and iOS can play back this format, and it is the only streaming format compatible with the iPhone, iPad, and iPod touch."
Not the first concession for adobe. (Score:5, Interesting)
Given Wallaby, Adobe's flash to HTML5 converter, this is by no means adobe's feat concession nor it's last. iOS is here to stay and adobe is slowly getting on board.
Re:Not the first concession for adobe. (Score:4, Interesting)
Back when they could actually claim adoption rates in 95+ percent range without the slightest doubt, I suspect that having client ubiquity certainly was helpful; but they would be insane to alienate the customers who actually buy stuff in some sort of fight to ensure that the customers who just download stuff and encounter ghastly security problems can continue to do so.
They will, presumably, walk away by half measures, in order to try to milk RTMPe and other benefits of flash client ubiquity as long as possible; but there is nothing inimical to their actual profit sources in building HTML5 related tools...
Re:Not the first concession for adobe. (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Aren't you worried your additional closing parenthesis without an opening one will cause the world to implode? Or do quotation marks negate the world-imploding power of a previously unopened closing parenthesis?
Re:Not the first concession for adobe. (Score:4, Funny)
Re: (Score:2)
Actually Adobe isn't all that interrested in Flash, it is just a technology they inherited when they bought Macromedia.
Just an few examples, Adobe worked many, many years on SVG. Supposedly they did a lof of fonts work for HTML5. They have a Flash2HTML5 convertor now (ok, just a first version which only supports a few things).
Re: (Score:1)
Flash is the key to their expensive creativity software monopoly.
If I can do HTML5 then why should I pay $$$ for all these expensive adobe packages? As long as flash is the defacto standard then I have to pirate or pay $800 to create ads or movies on youtube.
Notice Flash is still required for their solution. It just converts it back to html 5.
At least if I were an executive at Adobe I would be patenting anything under the sun related to video to force people to use flash instead of html 5 and of course do e
Re: (Score:2)
If I can do HTML5 then why should I pay $$$ for all these expensive adobe packages?
Maybe if Adobe has the best HTML5 content creation tool as well? They are revamping that side of their tools (i.e. DreamWeaver) in their "unheard of" point release CS 5.5.
Re: (Score:2)
Adobe does have a bunch of HTML5 tools coming up and ( some free and some not) add ons to existing tools.
Re: (Score:1)
Re: (Score:2)
As Adobe puts it, it is a tool for converting 'existing Flash content' to HTML5.
Re: (Score:2)
They realize that flash sucks ass.
There, fixed that for you.
Seriously, Flash was useful in its time - but technologies and protocols always improve. Flash's ubiquity was likely what's kept it relevant for so long. I doubt anyone (except the folks whose single skillset is a mastery of Flash development) would try to argue that it's the best solution for anything from a technical point of view.
Re: (Score:2)
Flash has definitely outlived its usefulness. It was cool back in 2000, remember all the amazing flash animations [coldhardflash.com] that made sites like Albinoblacksheep and Newgrounds popular ? Good stuff, but "Napster Bad" [youtube.com] was released 11 years ago ffs. That's like a century in internet years. Since then Flash has been abused for everything from atrocious "mystery meat navigation" [webpagesthatsuck.tv] type websites to obnoxious ads. We can do better now, it has outlived its usefulness and we should let it die already.
Comment removed (Score:4, Insightful)
Re: (Score:2)
Re: (Score:1)
All the above basically has changed. But so has windows, it's actually pretty good now (only 20 years to get there...), but various flavours of *nix have caught up in usability (for your average pleb here) but MacOs still has the hardware
Re: (Score:1)
Well Windows was never the best technically either but 90% of people use it. It's because it is what everyone else also uses.
When I look for jobs for webmasters I almost always see flash experience or dreamweaver with half of them out there. It is FAR from dead.
With fragmentation of Firefox, IE, and Chrome with html 5 between their new generation and last generation browsers it becomes a horrible headache to support. Making a flash video for animation rather than javascript or html 5 works with all of them.
Re: (Score:2)
As any iOS user can attest to, Flash is all but dead except for (and in this order):
For the first one, H.264 streaming works way better, people actively dislike the second one, and while Flash games can be fun, it's definitely not a deal breaker for most people.
I've gone with the "don't install Flash, just use Chrome when you do need it" method, and I've discovered that I rarely need it.
Flash is already dead. Sure, it'll be around for a few more years at least, and I imagine Flash games will b
Re: (Score:2)
More difficult to optimize? (Score:4, Interesting)
Re: (Score:2)
but does anybody have a technical explanation of why bog-standard RTSP, an RFC implemented by a bunch of vendors(including Apple), is worse than HTTP for media streaming? "More difficult to optimize" is pretty vague.
Maybe "more difficult to optimize" is a euphemism for "a more difficult patent minefield to transverse"?
Re:More difficult to optimize? (Score:4, Insightful)
I'm certainly not up on the details of live media streaming; but I've never seen a clear breakdown of why RTMP is obviously fucked compared to the alternatives.
Re: (Score:2)
Adobe's specifications for RTMP that they've released are incomplete at best and incompetent a worst. It's pretty much impossible to implement an RTMP server without a fair amount of reverse engineering effort. Not only does this open the implementer to lawsuits from Adobe but it's also prone to incompatible errors. Because HTTP encapsulation is optional and something that needs to be provided by the server you have to hope whatever implementation you're using is fast and clusters well.
With HTTP Live Stream
Re: (Score:2)
I've implemented several RTMP servers for gaming, telcos and sideprojects (www.voicehall.com), and found a ton of border cases and a few undocumented features. Besides there are patents on some mechanisms of server implementation, but the ones I've found are not difficult to get around (at least I could get around them for our applications).
Re: (Score:3)
What a dipshit. Apple's streaming server software has supported RTSP for a long time. Long before HTTP live streaming.
Re: (Score:1)
What a dipshit.
Webkit is open because of the GPL and the fact that KDE wrote the codebase that Apple wanted and didn't have the time or energy to write in a propietary fashion. Yes Apple has done a lot with this codebase and I won't take that from them, but if you believe that this codebase would be open if it weren't for it's GPL roots then I believe that you and Steve Jobs are having a beautiful baby together. iBaby 1.0.
http://en.wikipedia.org/wiki/WebKit [wikipedia.org]
Re: (Score:1)
GP is talking about Darwin Streaming Server and RTSP support. You're talking about WebKit, which has nothing to do with the subject.
I think this is one of those "better to keep your mouth shut and have people think you're a fool-" situations. Fool!
Re: (Score:1)
Don't care, either that is his sig and (s)he feels that it needs to be attached to everything (s)he types or it was typed as an addition to the comment. I think I should respond to a lie in both cases. Maybe you are not capable of reading that far into a comment or maybe you are just sticking up for a friend. Either way my response is valid and it is you who are the fool.
BTW in case you still missed it from the post here is the quote from what (s)he said.
"Webkit. You can thank Apple for being open when u
Re: (Score:2)
What a dipshit.
You're whining that Apple used open source properly. They took a basic web project, forked it, made it better, and share it.
And no, Apple doesn't do everything closed source. Peruse this and have your little mind expanded.
http://opensource.apple.com/ [apple.com]
And after that, you can go try to find any phone that natively uses KHTML for their web browser. And then try to find an Android phone that doesn't use Apple's Webkit source for their native browser. Then, reread my sig. Dipshit.
Re: (Score:1)
You are a Stupid Fu#?ing cult member and I shouldn't argue with a religious fanatic about his religion... But, my point is not that Apple didn't build upon it, it is that it wouldn't be open at all if Apple hadn't taken it from an open source project. Apple makes almost nothing from scratch that they give back. Read that list again and tell me which important projects they actually really started. It's not many. They took what they needed and gave back because usually they had no choice You give credit
Re: (Score:2)
In other words, they used open source appropriately. And you're SUPER pissed because they do some closed source stuff too. Got it. It's almost like you're a religious fanatic...who can only see one point of view.
Re: (Score:1)
Wrong again, the point is that it is not thanks to Apple and somehow your church thinks it is, and I am so sick of religious cults in every form. I own two Macs (one with System 6 because it is fun), an iPod touch. and an iPad (both for dev and testing purposes), as well as a boatload of other brands and types of systems and devices. I get around them better than most. I am not tied to any one system religiously or in any other way.
You however feel that you need to give credit at all times to your god ir
Re: (Score:2)
If you want to see how crazy you are/sound, switch Apple/Jobs for Google/Schmidt or Microsoft/Gates.
You're off your rocker because you don't like Apple. You need to get some perspective.
Re:More difficult to optimize? (Score:4, Insightful)
One issue is some networks block RTSP, but not HTTP.
Re: (Score:1)
Also reverse NAT-ing RTSP requires specific knowledge of RTSP in the router (it is like FTP in this regard). HTTP is a LOT easier to cluster than RTSP.
Re: (Score:2)
Re: (Score:2)
"Tunneling every protocol over HTTP" is the reality, especially HTTPS as you can't see what is inside.
Look at Gmail over HTTPS: email, IM, VOIP, and video chat.
I'm not sure this is really what we all wanted when we started blocking all those ports at firewalls, but it is what we got!
Not all optimization is technical in nature. (Score:1)
You need to keep in mind that not all optimization takes place at a technical level.
My suspicion is that RTSP is much harder to "optimize" at the marketing level. It just doesn't have the hype and buzzword-factor that HTTP has these days. This is especially important when it comes to Apple devices, where the consumers are generally far more technologically-clueless, and much more interested in marketing bullshit.
Apple consumers, in addition to the executives of companies interested in creating software or m
Re:Not all optimization is technical in nature. (Score:4, Insightful)
Re: (Score:1)
RTSP/RTCP is just for controlling the stream. The stream is streamed in RTP, which is must faster than TCP, think UDP with sequencing. HTTP/TCP will never be faster than RTSP/RTP.
Re: (Score:2)
Faster equals more unreliable.
Streaming video over UDP sucks because video codecs (e.g. h.264-avc) are not able to gracefully handle any packet loss/corruption. Voice audio codecs are generally very resilient to packet loss because that's what they are designed for. h.264-svc should fix the packet loss sensitivity, but good luck finding that anywhere.
That's totally ignoring the NAT bullshit, which can be solved with interleaving RTP streams into the RTSP TCP socket. But many RTSP clients (I'm looking at yo
Re: (Score:2)
That is because a good portion of the people streaming out there over UDP are doing wrong. MPEGTS is designed for a lossy broadcast style operation. Its designed to run on ATM cells, which is why each "packet" is 188 bytes. Those packets can contain error correction information. That requires more total bandwidth but is much better for multicast sending because you don't need to retransmit, and you don't need to get back and ACKs. It also contains flags that let the recipient know if the data in the pa
Re:More difficult to optimize? (Score:4, Interesting)
The RTSP protocol is pretty complex compared to HTTP streaming. For example, the RTSP doesn't specify the underlying transport, which "normally" is UDP with TCP fallback. Due to these complexities cell phone vendors have a hard time implementing bug free RTSP support in their video players. Seeking (in VODs) for instance was not supported on any device I tried (most popular handsets in the EU at the time). RTSP was obviously specifically developed to stream multimedia so it has a lot of features HTTP lacks (bandwidth detection, time synchronisation, mulitple streams etc). However plain HTTP streaming is good enough for 95% of the use cases.
It's funny though, because Apple wrote DarwinStreamingServer, which for a long time was the best free RTSP server available.
Last time I worked with RTSP was about 3 years ago so stuff may have changed (tm).
Re: (Score:2)
RTP over UDP or TCP can be blocked simply by blocking the ports. Especially for cell phones and other mobile devices, assume port 80 is open -- and everything else is blocked. Maybe port 443. ISPs are only slowly investing in enough DPI hardware to block HTTP streaming, so look to port 443.
Seeking, fast forward, and rewind (a.k.a. trick play) will fall over when using an incompatible HLS server/client combination, but the upside of it all is that if you want, you can host a pre
Re: (Score:1)
Proxies, the past and the future. The rest of the firewall will be be nothing much in the end. If I want to verify who and what is at my door I must analyze everything that knocks and everything that lurks in the street. MITM at the firewall must be the norm soon if you want to deal with the real world for your corporate network. If you are average Bob user trying to deal with your ISP and government you must figure out how to deal with this as well. In the end it's all just data I guess.
Re: (Score:2)
As a result, RTSP will lose to HTTP Live Streaming.
Re: (Score:1)
I'm certainly not claiming this is about the user experience. I'm simply saying that the more we tunnel the more we need to proxy and throttle (at least for a corporate network). Everyone keeps using 80 and 443 because they know that those are open. It is a vicious cycle. Maybe we just need 2 ports for TCP one for clear text and one for encrypted (some sarcasm intended here). Firewalls that don't have a good proxy are no firewall at all. QOS??? PROXY???
Re:More difficult to optimize? (Score:4, Informative)
My understanding is that this is purely about ease of use of getting through firewalls, NATs and PATs. Everything passes HTTP, and there is no other transport protocol (not even UDP over port 80) for which that is true.
Re: (Score:2)
but does anybody have a technical explanation of why bog-standard RTSP, an RFC implemented by a bunch of vendors(including Apple), is worse than HTTP for media streaming? "More difficult to optimize" is pretty vague.
I don't know for certain, but the newer method is supposed to encapsulate the media into 10 second chunks. This would allow the media stream to change quality as it is playing. This can be handy if the user, for example, switches to full screen mode and requires a higher quality stream. I know the older RTSP standard also supported multiple different quality streams but I do not believe you could switch between them as the media is playing.
Considering that this newer method makes use of standard forma
Re: (Score:1)
With HTTP streaming you can rely on a pool of beefy reverse proxies like Varnish or Nginx to handle the load, or let the CDN handle it as any normal HTTP traffic.
HTTP is relatively common and relatively easy to handle/debug. I'd prefer not having to study another protocol ;)
Now, the interesting stuff is to provide Apple's HTTP streaming, MS' Smooth streaming and any other HTTP, chunk-based protocol from the same, unchunked video file using a webserver plugin to do the chunking on the fly. I know about the U
Re: (Score:2)
Re: (Score:2)
Its not. In fact its easier. RTSP is designed specifically with streaming data in mind, and accepts lost packets even. HTTP being on TCP has the problem of retransmits clogging up the pipes and slowing down transmission on busy or not-quite-perfect connections.
Re: (Score:2)
As far as transport is concerned, RTSP using a direct TCP connection is quite efficient with barely any slack, however RTSP over HTTP (say behind a firewall that only lets through HTTP requests) is quite nasty and not so efficient. It's not difficult to design a better protocol for streaming over HTTP, especially if you don't care about latency very much. A smart design would also name chunks in such a way that addressing the same (live or not live) streams by multiple clients could allow caching by HTTP pr
Re: (Score:2)
Re: (Score:3, Funny)
I remember back in the late 90s when we had hubs, not switches, someone came up with a perl script to monitor the wire looking for .gif and .jpg files and would then tile them on a display screen with the IP of the host viewing them. The sales department at that ISP sure got in trouble that day!
Re: (Score:2)
Re:IOS (Score:5, Informative)
Apple actually licenses the trademark iOS from Cisco. There's no evil theft going on.
Re: (Score:2)
And he therefore missed the whole joke.
Borg (Score:3, Funny)
So, are we going to get a Steve Jobs Borg icon soon?
Or a generic borg in a black faux turtleneck and jeans?
Just any old borg with the Apple logo on it?
Resistance is futile. You will abandon Flash.
Sign me up. Gimme my implants!
Already supported on Android 3.0 Honeycomb too! (Score:2, Interesting)
You can view the live streams on Android Tablets running Honeycomb.
I just tested this at work the past week. Didn't have to do anything different using the Wowza Streaming server and Wirecast Encoder. One stream played on both an iOS iPad and Motorola Android Xoom tablet.
Re: (Score:1)
I just tested this at work the past week..
And I'm sure it didn't have anything to do with your job function either.
There Goes My Undeserving Superiority (Score:3, Insightful)
Re: (Score:2)
First, there is no standard for WebM bandwidth-adaptive streaming yet, over HTTP or any other protocol. Secondly, a quote from that site:
One word about the adaptive bitrate mechanism on WebM : contrary to other OTT technologies, adaptive bitrate settings are controlled on the server side only...
So, it holds state on the server, meaning it requires custom server software, and therefore doesn't scale cheaply. The beauty of the streaming-over-HTTP solutions is that you can take advantage of the huge number of caches in CDNs, ISPs, and corporations for free. We did some testing, and around 75% of our visitors are behind some form of caching proxy (we're a B2B company
So is this is a win for Linux? (Score:3)
Does this mean we can also piggyback off of the Apple concession to get access to the HTTP stream without having to go through Flash?
Re: (Score:2)
Should only be a matter of sending the right User-Agent.
Re: (Score:2)
Adobe CS HTML 5 Edition (Score:1)
So, to me, the only logical thing to do during the few years when flash will still dominate (old browsers, windows xp, online video, inertia, etc) is to add the ability for all of their product suite to output to html 5.
I see people here saying they don't rea
Anyone defending Flash anymore? (Score:2)
When I think of "Flash", I think of animated characters bouncing around, trying to sell me awful products, and websites that have a loading bar, "in just 10 seconds you'll be able to see the simple text, but once you click a link, it has to load THAT Flash page too! This is
Re: (Score:1)
Why HLS??? (Score:2)
What is Apple's obsession with HTTP Live Streaming?
The only way you are going to get iPhone/3G/4G scalable broadcasts is with 3GPP's Multimedia Broadcast and Multicast Services (MBMS), and as far as I know this depends on a multicast UDP/RTP framework. As of right now, you can't use RTP with the hardware acceleration of H.264 decoding in the iOS Core Media Framework, only HLS.
I understand why CDNs like HLS (the ease of using HTTP caches for distribution and getting through firewalls), but at the mobile ter
Good for Roku owners (Score:2)
M3U Format Standard Spec? (Score:2)
Where is the spec for an M3U format standard published?
Re: (Score:2)
Based on the draft RFC for HLS, there is no spec for an M3U standard format. "What WinAmp does" is not a spec for a standard format.
Apple's HLS draft RFC specifies the definitions of new tags in the Extended M3U format to make an Apple HLS format. But M3U itself is not standardized.