Adobe Adopts HTTP Live Streaming For iOS

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.

[RyuuzakiTetsuya]

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.

More difficult to optimize?

[fuzzyfuzzyfungus]

RTSP has the major disadvantage of not infrequently including assorted vendor's special secret sauces, meant to drive lock-ins between server software and client software(and/or satisfy somebody's demand for DRM); 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.

Already supported on Android 3.0 Honeycomb too!

[Anonymous Coward]

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:Not the first concession for adobe.

[fuzzyfuzzyfungus]

Given that(with the exception of licensing embedded clients, which(if the dire performance on Android is any indication), they'll have increasing trouble even giving away... Adobe's client side flash/AIR stuff is a pure cost center designed to drive sales of their content-creation suit and assorted server offerings, they don't really have anything to gain by attempting a fight to the last on the client side.

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:More difficult to optimize?

[Anonymous Coward]

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).