Follow Slashdot stories on Twitter


Forgot your password?
IOS Iphone Media Media (Apple)

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."
This discussion has been archived. No new comments can be posted.

Adobe Adopts HTTP Live Streaming For iOS

Comments Filter:
  • by RyuuzakiTetsuya ( 195424 ) <taiki AT cox DOT net> on Saturday April 16, 2011 @07:24PM (#35843800)

    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.

    • by fuzzyfuzzyfungus ( 1223518 ) on Saturday April 16, 2011 @07:33PM (#35843844) Journal
      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...
    • by Lennie ( 16154 )

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

      • 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

        • by toriver ( 11308 )

          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.

          • by Lennie ( 16154 )

            Adobe does have a bunch of HTML5 tools coming up and ( some free and some not) add ons to existing tools.

        • by ulski ( 1173329 )
          There is another option. Instead of paying Adobe you could download the free FLEX sdk from Adobe together with the free IDE called FlashDevelop. (See http// ) I have used Flashdevelop + the FLEX sdk, and it works quite nicely - but I guess the paid for software is lot more efficient, when it comes to GUI design/layout.
        • by Lennie ( 16154 )

          As Adobe puts it, it is a tool for converting 'existing Flash content' to HTML5.

  • by fuzzyfuzzyfungus ( 1223518 ) on Saturday April 16, 2011 @07:26PM (#35843806) Journal
    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.
    • 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"?

      • by fuzzyfuzzyfungus ( 1223518 ) on Saturday April 16, 2011 @07:39PM (#35843868) Journal
        The patent system works in mysterious ways, so there certainly could be a giant clusterfuck of submarine patents lurking out there; but the RFC was released in '98, and the list of vendors and OSS projects with source, sink, or both support is not a short one(and includes Apple's own proprietary OSX server media streaming package). Whatever video/audio codecs you are streaming on top of RTMP are almost certainly going to land you in a giant heap of trouble; but I would expect RTMP itself to either be harmless or driven into some sort of cross-licensing stalemate by now. Individual vendor extensions, of course, particularly DRM related ones, for which the DMCA can come to the field, are presumably a mess; but Apple's ability to say "The RTMP that is real RTMP is the RTMP that iOS recognizes as such, suck it down." would seem to be equal to its ability to say "HTTP live streaming is the new flavor of the month. RTMP is dead."

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

    • by gig ( 78408 ) on Saturday April 16, 2011 @07:35PM (#35843850)

      One issue is some networks block RTSP, but not HTTP.

      • by Anonymous Coward

        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.

      • Is tunnelling "every protocol known to man" over HTTP the answer? If you allow HTTP through the firewall today, you're essentially allowing anything. If the firewall blocks RTSP, it's probably because the owner of the network didn't want all the bandwidth taken up by realtime streaming media...
        • by TheSync ( 5291 )

          "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!

    • 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

    • by Anonymous Coward

      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.

      • by vipw ( 228 )

        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

        • by DarkOx ( 621550 )

          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

    • by Anonymous Coward on Saturday April 16, 2011 @07:50PM (#35843918)

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

      • by dch24 ( 904899 )
        You've hit it on the head.

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

          • by dch24 ( 904899 )
            Your solution is technically sound but the user experience is horrible.

            As a result, RTSP will lose to HTTP Live Streaming.
            • 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???

    • by mbone ( 558574 ) on Saturday April 16, 2011 @09:04PM (#35844234)

      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.

    • 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

    • by Reez ( 65123 )

      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

      • by qbast ( 1265706 )
        Try Wowza Media Server. RTMP live stream (or RTSP or MPEG2-TS over IP) goes in, whole bunch of other protocols come out - RTSP, RTMP, Apple's HLS, Adobe's HLS and MS Smooth Streaming. It does VoD too. Put Flash Media Live Encoder (free) and Wowza together and you can stream to any existing device.
    • 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.

    • by ModelX ( 182441 )

      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

  • Borg (Score:3, Funny)

    by Anonymous Coward on Saturday April 16, 2011 @07:30PM (#35843826)

    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!

  • by 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.

    • by Nethead ( 1563 )

      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.

  • by selex ( 551564 ) on Saturday April 16, 2011 @08:23PM (#35844036)
    Now I can't stick my nose up at all those iPhone uses when I show them Flash enabled web content on my Droid. Thanks Adobe. Selex
  • by Compaqt ( 1758360 ) on Sunday April 17, 2011 @12:27AM (#35845184) Homepage

    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?

  • The way I see it is that flash is valuable to Adobe because they have based all their product list ( did anyone browse Adobe's product list? I don't even understand what half f those do and I'm in IT/web) on flash output and on flash been ubiquitous.
    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
  • I remember the defenders at first, but over the last six months, Flash seems to be getting kicked about more and more. I've long hated the damn thing, I grew over it after making heavily Flash based Homestead websites in highschool!

    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
  • 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

  • Roku boxes have supported HLS for a while now, but don't support RTSP. More content in HLS means more channels for the Roku (public and private).
  • Where is the spec for an M3U format standard published?

I am a computer. I am dumber than any human and smarter than any administrator.