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

Comments

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.

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

[spud603]

Syntax Error: unmatched "(" in nested parenthetical near line 1.

Re:Not the first concession for adobe.

[Lennie]

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

[piripiri]

There you are).

Re:Not the first concession for adobe.

[Anonymous Coward]

A lot of Adobe employees have iPhones and iPads. They realize that nobody misses flash and flash is becoming irrelevant. A lot of Adobe employees have android phones. They realize that flash on a smart phone sucks ass.

Re:Not the first concession for adobe.

[93 Escort Wagon]

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

[spud603]

Thanks! and with this: ")" I can finally stop scanning.

Re:Not the first concession for adobe.

[fuzzyfuzzyfungus]

I can' t argue with your correctness(or my error). I can suggest that you really should study for that Turing test a bit...

Re:Not the first concession for adobe.

[CharlyFoxtrot]

Flash has definitely outlived its usefulness. It was cool back in 2000, remember all the amazing flash animations that made sites like Albinoblacksheep and Newgrounds popular ? Good stuff, but "Napster Bad" 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" type websites to obnoxious ads. We can do better now, it has outlived its usefulness and we should let it die already.

Re:Not the first concession for adobe.

[hairyfeet]

You know what? I don't think it is so much that "flash sucks" so much as when Adobe bought it they didn't really have a game plan and the code they had only ran on win X86 and frankly that is the same to this day. Flash on win x86? It runs just fine. Runs fine in Win X64 since the browsers are all 32 bit. Everywhere else? Steaming pile of stinky.

So it looks, just from me watching the history of the thing, that they made the classic buyer's mistake. they probably let everyone that was really good at the code behind flash waltz out the door and then milked it for all it was worth. But times change, win x86 isn't the end all be all anymore, and it looks like Adobe simply hasn't been able to keep up.

But then again Adobe never were the brightest bulbs in the sign. Macromedia Xres was a great image manipulation software that they could have sold very nicely in the low to mid market, and used it as an upsell to Photoshop. They have also bloated the living shit out of PDF by jamming everything AND the kitchen sink into what was supposed to be a portable office format, not a fricking office suite or multimedia presentation, with predictable results.

So to me the questions are thus: Will Adobe be able to adapt, or will they go the way of the 8 track? And if flash goes tits up, what will replace it? Because frankly from what I've seen HTML V5 sucks on less than a dual core unless you have some sort of acceleration for it. H.26x is great and does have acceleration, but FOSS won't touch it because of patents, WMV is okay but only on Win, Quicktime sucks, Theora would have been great 10 years ago but sucks now as it eats too many cycles for less quality than H.26x, so what is left?

Because I REALLY don't want to go back to the 90s, with a dozen competitive formats all with bugs and hassles, and since it looks like Apple and MSFT are sticking with HTML V5 H.26x that will end up fractured. Sigh, I have a feeling it is gonna be a big clusterfuck like the 90s all over again. Say what you want about flash, but at least every machine from a PIII to the latest multicore could run it, and nearly everyone already had it installed.

Re:Not the first concession for adobe.

[Anonymous Coward]

http://www.webpagesthatsuck.tv/saturn/saturn.html

Requires Flash for the video (that sucks) and the banner graphic (with pixel text that should be HTML text) is in JPEG (correct format for the baby picture but not the rest which should be in PNG).

That's THREE SUCKS on a website about websites that suck. At least the layout is in CSS and not tables.

Re:Not the first concession for adobe.

[kiddygrinder]

flash has always sucked, it's good on x86 now because they've bug fixed the steaming pile of crap for years and they've actually managed to get it pretty stable. if you're looking for the next big thing in delivering video content it's probably going to be google's v8 thing, since they own youtube and that's 80 % of all video content right there, as well as being open source so the zealots can feel good about it (saying that with love since i am one).

Re:Not the first concession for adobe.

[Billly Gates]

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 everything to prevent adoption. Adobe didn't inherit shockwave. They bought it to control it because they viewed it as a threat to their movie editing products.

Re:Not the first concession for adobe.

[Billly Gates]

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. So developers will stick with flash.

Worse Adobe stomped out all the compeition for a graphical ide for web development. Frontpage is gone and sharepoint is really for intranet sites that still use IE 6. So flash is will stay for a long time.

I pray a free tool comes out or at least more competition. Flash is like Microsoft's .doc file format that forces everyone else to keep using MS Office. Technology improvements are not developers need the tools. A gui is needed as you can't make a cool game or flashy objects in vi and firebug. Come on ...

Re:Not the first concession for adobe.

[Anonymous Coward]

"Sigh, I have a feeling it is gonna be a big clusterfuck like the 90s all over again. Say what you want about flash, but at least every machine from a PIII to the latest multicore could run it, and nearly everyone already had it installed."

Which is why Flash is not going anywhere. Unfortunately, we ended up with Windows due to people demanding standards. We ended up with the lowest quality product. Same is true with flash and why HTML 4.01 is here to stay with it. I would love to make html 5 content for my sites but realize it is not worth the hassle. Offices that will browse them (business 2 business) still use IE 6 and flash is the only way to go and I am willing to support for the next 5 years.

Re:Not the first concession for adobe.

[Anonymous Coward]

Unfortunately. It took a crappy walled garden to force the hand of crappy plugin. Not sure if that exchange though was worth the cost. Seems one moderately boring, lesser evil was supplanted by a greater evil. Freaking Macintosh model resurfaced as i* devices

Too bad no one else can get their ass in gear. Google doesn't seem to have enough control over Android and code doesn't work across devices generally from anecdotal reports. Linux can't put together a decent desktop and install package ever since Ubuntu went to shit. HTML5 can't supplant most of Flash's figures. And Apple has us stoned by to the stone age using skills honed when the Macintosh chose to use extensions.

Computing SUCKS these days.

Re:Not the first concession for adobe.

[TrancePhreak]

Playing audio quickly and consistently in browsers is still something Flash is better at. Animating sequences, interactive content, and playing video (at least on Windows) are all still better in Flash. Things like HTML5 / javascript / svg might take over, but that's still in the future.

Re:Not the first concession for adobe.

[toriver]

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

[bemymonkey]

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.

[ulski]

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//:www.flashdevelop.org ) 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.

Re:Not the first concession for adobe.

[node 3]

As any iOS user can attest to, Flash is all but dead except for (and in this order):

1. Video
2. Ads
3. Games

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 be around for a long time as well (although a more proper game plug in could reasonably supplant it), but as a "must-have, default plug in", Flash is on its way out.

Re:Not the first concession for adobe.

[MeateaW]

Sorry, but Windows isn't the lowest quality product.

• From a non-technical users perspective, *nix was the lowest quality product (no ease of use)
• Windows was the cheapest product (no special hardware)
• MacOS was expensive (hardware lockin)
• And anything else was too small.

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 lockin (arguably though, completely artificial hardware lockin...)

Re:Not the first concession for adobe.

[Anonymous Coward]

Don't worry, it matches the quoted open parenthesis in the syntax error line. I think, though the nesting would be wrong, but in any case there is an equal number of open and closed.

Re:Not the first concession for adobe.

[Lennie]

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

Re:Not the first concession for adobe.

[Lennie]

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

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.

Re:More difficult to optimize?

[WrongSizeGlass]

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?

[gig]

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

Re:More difficult to optimize?

[fuzzyfuzzyfungus]

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.

Re:More difficult to optimize?

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

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

Re:More difficult to optimize?

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

Re:More difficult to optimize?

[NatasRevol]

What a dipshit. Apple's streaming server software has supported RTSP for a long time. Long before HTTP live streaming.

Re:More difficult to optimize?

[Graymalkin]

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 Streaming the server can be a bog standard HTTP server, streaming logic is in the client and the tool that writes the playlist file. All of the techniques for optimizing HTTP resouces (clustering, etc) work the same for Live Streaming as they would for normal video hosting. You can also dump the source files on whatever CDN you have available rather than requiring it support a custom server package.

Re:More difficult to optimize?

[mbone]

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

[dch24]

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 prerecorded HLS stream on any plain vanilla HTTP server. Bingo -- "Easier to optimize" should be read as "nothing can compete with the simplicity of an HTTP server."

Those same firewalls that block everything? They often have a transparent proxy on port 80. So you don't write a new protocol, you find a way to make HTTP work. By work, I mean "it just works." Everywhere.

Re:More difficult to optimize?

[willy_me]

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 formats and protocols, there has to be a reason why it was developed. There is nothing here that could act as a "submarine patent" and it should be easy for just about anyone to implement.

Re:More difficult to optimize?

[Anonymous Coward]

Http streaming works pretty seamlessly with internet services like Akamai, and can also give you access to live content with DVR capabilities easily. For instance, you can build up a directory with multiple chunks in it, and allow you to pull chunks from various parts of a program without anything more complicated than reading an index file and figuring out where you want to stream from. RTSP can stream content, but rewinding or fast forwarding through the content requires you to send commands to a server, which then must customize the rtsp stream axxording to your commands.
    With http streaming you just ask the http server for a file, and it delivers the file to you wihout really caring where from the stream you are playing from. The connection between server and client is stateless, and therefore more scalable.

Re:More difficult to optimize?

[Anonymous Coward]

I've worked a little bit on implementing an RTMP server, and the open spec is actually pretty straight-forward and well defined. It can be found here: http://www.adobe.com/devnet/rtmp.html

Re:More difficult to optimize?

[Reez]

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 Unified Streaming Platform, but there doesn't seem to be many players in that field right now ;)

Re:More difficult to optimize?

[qbast]

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.

Re:More difficult to optimize?

[Jon Stone]

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

Re:More difficult to optimize?

[TheSync]

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

Re:More difficult to optimize?

[vipw]

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 you Android), don't support that.

It's telling that in Android 3.0, they added HLS instead of a reliable TCP transport to RTSP. RTSP on the open internet is dying, and only makes sense to use if the underlying UDP streams are being multicast.

Re:More difficult to optimize?

[MikeBabcock]

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

[stilldead]

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

Re:More difficult to optimize?

[ModelX]

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 proxies. The caching issue alone would be the big plus of a good HTTP streaming implementation, otherwise you can't do much better than RTSP over TCP.

Re:More difficult to optimize?

[ModelX]

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

[DarkOx]

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 packet is a place where a given program stream can start decoding from, IE for a video a full frame.

The problem is most of the time the error correction information is not sent, so more data can be used for content, and half the time other container formats like MPEGPS get used which are simply not designed for transmission. So yes if you have packet loss it fails badly.

Re:More difficult to optimize?

[Gizzmonic]

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

[stilldead]

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 using the browser on your phone."

Re:More difficult to optimize?

[NatasRevol]

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/

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

[stilldead]

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 to your great Saviour but none to anyone else. If you honestly think that without Apples work no one would have a browser on their mobile phones I am willing to say you are damned liar. Apple would have given back nothing if they had started this thing from scratch. Apple used that code because it was short, fast, and very efficient and they didn't think they could duplicate it on their own in the time frame that they had. They needed it as their foundation which brings us back to the GPL and why they had to give back what they added. I would also point out that if you think Apple is the only contributor you are VERY WRONG. In fact if you go and look you find that google (and chromium) and many other people and companies have some of the largest contributions and that this is anything but an Apple only project even now.
https://www.ohloh.net/p/WebKit/contributors?commit=Update&page=1&query=&sort=kudo_position

It is not thanks to Apple, it is thanks to so much more.

Re:More difficult to optimize?

[stilldead]

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

[NatasRevol]

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

[stilldead]

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 irrelevant of the actual truth. Praise the Lord Jobs and Hallelujah. It is just like other religious cults. Say a bad accident happens and the emergency room doctors work through the night to save a life. They refuse to give credit to anyone but their god when the doctors in the hospital are the ones who did the work. Where was that god one hundred years ago when the same person would have died and where will Steve Jobs be soon for that matter?

Feel free to get the last word from here as I am done checking this post. I am however impressed that all of your posts on this old thread keep getting modded up???

Re:More difficult to optimize?

[dch24]

Your solution is technically sound but the user experience is horrible.

As a result, RTSP will lose to HTTP Live Streaming.

Re:More difficult to optimize?

[stilldead]

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?

[NatasRevol]

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.

Borg

[Anonymous Coward]

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!

[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:Already supported on Android 3.0 Honeycomb too!

[Nethead]

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.

Not all optimization is technical in nature.

[Anonymous Coward]

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 media targeting Apple's devices, don't really know what HTTP is, but they damn well know it has something to do with Web 2.0 and Facebook and Twitter, so it must be chic. It's just not possible to build up the same hype when using RTSP or some other protocol.

Re:Not all optimization is technical in nature.

[immaterial]

What are you smoking? "HTTP" has zero "buzzword-factor," and the average Internet user (clueless executive or otherwise) doesn't connect it with anything, beyond (maybe, if they're paying the slightest bit of attention) "those pointless extra letters in the address bar."

Re:Not all optimization is technical in nature.

[Anonymous Coward]

Mod up parent

Re:IOS

[fuzzyfuzzyfungus]

Just fire up SPAN against whatever port the guy with the office's stickiest keyboard uses and you can watch all the porn you want...

Re:IOS

[Nethead]

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:IOS

[fuzzyfuzzyfungus]

Depending on the flavor of porn preferred in that location, that arguably qualifies as an 'intrusion detection and visualization system', of a sort...

Re:IOS

[Roogna]

Apple actually licenses the trademark iOS from Cisco. There's no evil theft going on.

There Goes My Undeserving Superiority

[selex]

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

Finally

[Anonymous Coward]

This piece of shit (RTSP) is gone

Live WebM Streaming?

[Anonymous Coward]

Does this support live WebM streaming? And if so, what makes it better than this implementation: demo.anevia.com:8080/ott/webm.php. It seems like live streaming is a solved problem for WebM.

Re:Live WebM Streaming?

[Thundersnatch]

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). That means as much as 50% of our video bill can be covered for free by our customers if we switch to an HTTP based streaming solution. Note that progressive download over HTTP doesn't get high hit ratios, because many (most?) caches have some default maximum file size limits to prevent one user from blowing out the cache. HTTP-based streaming, with its smallish (10-second) chunking, solves that problem.

Re:IOS

[Anonymous Coward]

God forbid you should do 5 minutes of reading before opening your mouth.

Flash is the new IE6.

[Anonymous Coward]

I said it here before, and I will say it again, All real web developers are using HTML5 with its opensource features, and only emo hipsters use flash for their "cool" websites while the grown ups are using professional HTML markup.

Really? Adobe, way to take way too long

[Anonymous Coward]

MPEG-TS! OMG. Adobe, you're late, a little too late. Should have done this a long time ago.

So is this is a win for Linux?

[Compaqt]

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:So is this is a win for Linux?

[rrohbeck]

Should only be a matter of sending the right User-Agent.

Adobe added its own HTTP-based streaming feature.

[Anonymous Coward]

Adobe added its own HTTP-based streaming feature to Flash Media Server last year. Similar to Apple's solution, it breaks up H.264 video into chunks saved as separate files and sends those files to a client over HTTP. The difference is that its HTTP Dynamic Streaming uses an XML-based manifest file (instead of a plain-text playlist file) and the MPEG-4 fragment container format (.f4f). Also, it's only compatible with Flash or AIR.

siri
siri stocks

Adobe CS HTML 5 Edition

[cripkd]

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 really need Adobe's productivity suite because they can code html 5 by hand. The thing with javascript (and i love javascript) and canvas and all the new standardy stuff is that it's still a nightmare to code everything by hand and take care of all the different browser implementation for various canvas stuff or video support.
So what we need in order to build solid html5 stuff fast and using a nice workflow is a very nice IDE, some sorts of bastraction layers for video and graphics so I don't end up doing browser detection and other scripty stuff. And Adobe will occupy this market again if they are smart and just have their current tools export html5.

Re:Adobe CS HTML 5 Edition

[Anonymous Coward]

+1 this. Flash taught me that web development doesn't have to be a nightmare of tangled hacked-together technologies. If they can make HTML5 as easy to develop as desktop applications (like they did with flash), then we'll see a lot more great web applications by individuals.

Re:IOS

[Nethead]

And he therefore missed the whole joke.

Re:Adobe added its own HTTP-based streaming featur

[qbast]

It is actually much more similar to MS Smooth Streaming than to Apple's HLS.

Anyone defending Flash anymore?

[dafing]

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

I've long seen Flash as slow, annoying, buggy, insecure, and never optimised for my particular screen resolution. Apparently it absolutely sucks down The Juice on portable devices too. I hate waiting for a site to load, to then have it fill precisely a third of my screen real estate, having been designed for a computer resolution last common in a year beginning with 19.

The sooner Flash gets the hell out of here, the happier I'll be. I've never ONCE missed Flash while using my iPad or iPhone, in fact, I'd rather not have it on my iMac either!

Re:Anyone defending Flash anymore?

[scottschor]

http://7.mshcdn.com/wp-content/uploads/2010/06/apple-flash-woot.png

Why HLS???

[TheSync]

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 terminal level, it will always be a one-to-one TCP connection, not a many-to-one broadcast.

Good for Roku owners

[Scyber]

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

M3U Format Standard Spec?

[Doc Ruby]

Where is the spec for an M3U format standard published?

Re:M3U Format Standard Spec?

[Anonymous Coward]

They define it adequately in the draft itself, and refer to wikipedia.
It's not a particularly controversial or hard to parse format.

Re:M3U Format Standard Spec?

[Doc Ruby]

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.

Re:M3U Format Standard Spec?

[Anonymous Coward]

I don't see how that would matter, since the draft defines the format and its interpretation in its entirety. At no place does it defer to Winamp's behaviour.
If you find any ambiguity in the specifications, I'd suggest you email the draft authors.