More like a derivative of abrogate [merriam-webster.com], as in the course of action they took to abolish the effectiveness of one Dmitry Sklyarov [wikipedia.org] for pointing out how silly their "encryption" was at a security conference.

Give the guy a break, he was using speech recognition software and eating a slice of pizza and drinking a large Pepsi at the time. At first what he uttered was recognized as: "A booby too open feel them massaging pro thug all."

Because!
There's already a lot of good reasons why one should do a Flash-related project in haXe (shared front- and back-end code, pretty language, completely open-source, etc...). With RTMP support there would be one less excuse for not doing so.

First, it's got the same problem as any other proprietary application which opens specs -- there's only one implementation, and that implementation is proprietary. Most specs at least include a reference implementation.

More importantly, how long have the specs been open? Last I checked, they were only open for developing anything but a client/viewer.

That's why "open Flash" is a scam. Adobe gives you the specs but not the patent licenses (since they don't own many of the patents anyway) and tells you that you're all set to write your own open source Flash player.

Even so, it's still got the same problem Silverlight does: The open source project has to catch up from the beginning (8 months of the spec being open vs 13 years of Flash), while the proprietary version marches ahead.

It's good that they're opening up RTMP but they just released RTMFP/Stratus which looks like it's going to be very interesting. I want to create a system based on top of RTMFP but I don't want that system to be at the mercy of Adobe. Hopefully someone (like the guys behind Red5) will reverse engineer the Stratus interface.

What you will find is that Adobe made it difficult to legally work on an open source viewer, and that the specs that exist are either (1) leaked, and therefore it is questionable whether you can legally use them, or (2) from a clean room reverse engineering.

Gnash development has been done using a Clean room reverse engineering technique. By agreeing to the license for the Adobe (formerly Shockwave) Flash player, a developer gives up the right to develop a competing product.

Rob: The Adobe EULA for Flash forbids anyone who has installed their Flash tools or plugin from working on Flash technologies. This has had a chilling effect on the development of free Flash players, since a developer must either choose to decide that Adobe won't sue them over this, or to do what Gnash does, which is a slow and inefficient, clean room, reverse engineering project.

Adobe has declined to comment on this issue, since the confusion benefits their lockin of the market. Although Adobe has said they support Open Source projects, and donated Tamarin to Mozilla, we'd love to see a public statement that Gnash developers won't be subject to a lawsuit. It's very difficult to find developers that have never installed the Adobe software ever, which is what we've been doing to maintain our clean room approach.

GP doesn't know WTF they're talking about......but they're right. PDF is an open standard, implemented by other vendors in a way that sucks, yet Acrobat still sucks.

In fact, Adobe has never really been known for performance. For another fun test, take a Flash video, download the FLV, and play it in any other player. Compare CPU usage.

Last I tried this, in Flash, it was over 50% of a core. In VLC, or mplayer, or pretty much anything else -- despite the fact that this is FLV, which is presumably designed for Flash -- and it's less than 1%.

Actually, there is a PDF format that is an ISO standard, but there are other PDF formats that Acrobat uses that aren't based on the ISO standard. I just opened Acrobat 9 to check, and the PDF that complies to the ISO standard isn't even the default.

If you click PDF/A, for example, from the drop down list, you are then presented with a dialog to supply some options. Certainly the ISO standards are well-supported, but they're not user friendly, and I highly doubt most people will go through the hoops to use

Amen to this. This issue is the only reason I rip Hulu videos instead of just viewing them directly. The ads aren't that intrusive and ripping is less convenient than putting up with a few ads.

The problem is that on my HTPC (An older machine, Athlon XP 2800+), the Flash-based player is unable to play back video at full speed. mplayer, on the other hand, plays back ripped Hulu videos with plenty of CPU to spare.

Out of curiosity, what do you use for ripping Hulu videos? I've tried a couple of the Firefox extensions for downloading FLVs, but never had much luck.My home system is on the old side, and although it can play DVDs, etc just fine with MPlayer, it often chokes on low-res flash videos.

Problem is that Hulu doesn't use HTTP, they use RTMP (See TFA...) for the actual streaming.

For a while there were only Windows-based commercial programs (Replay Media Catcher and one other program), but now there is rtmpdump for other platforms - http://sourceforge.net/projects/rtmpdump/ [sourceforge.net]

It's pretty no-frills but their Hulu fetcher works. The documentation isn't the best, and the "quality" parameter to get_hulu is nonintuitive - 0 is the high quality 480p stream, 1 is the normal quality stream, 2 is an even

Last I tried this, in Flash, it was over 50% of a core. In VLC, or mplayer, or pretty much anything else -- despite the fact that this is FLV, which is presumably designed for Flash -- and it's less than 1%

I think FLV may be a container format, not codec. I think it uses VP6 for the actual video data, which was not designed for Flash.

i still cant use proprietary ATI drivers (on kubuntu 8.04) and flash. I find it varies incredibly by player too.youtube -> no problemiplayer -> drops frames after about 30minsother flash players (warez, etc) imediatly drop most of the frames.

The Flash Player certainly could do hardware acceleration, if it didn't suck. That was my point.

And, while I can understand that pixel-precision in the context of video as part of a larger application -- though I still would think that GPU-accelerated polygons would be better than pure-software vector graphics, for non-video elements -- what about the case where you're using Flash purely to play video?

My argument would be, that is a gross mis-use of Flash, or anything like it. Embed the video directly with

Well- if one creates their own player in AS3 and do not use the overwhelmingly awful FLVPlayback component, it gets better- but still not great.

My big question here is that Apple open sourced Darwin Streaming Server a while ago and clearly their handling of different *standard* vid formats is FAR superior to Flash. They have both RTSP and a secure(SSL) version. Why the hell don't people use that?

New versions of Flash support hardware acceleration, so if both your Flash player and the Flash application can do it, performance is more betterer. May as well check to make sure you're using an up to date plugin, although there's obviously nothing you can do if the Flash object wasn't compiled with hardware acceleration support.

WTF is your problem with PDF. Flash is a pain in the ass, and a lot of their new software stinks, but to be honest, Adobe has done a lot of things right over the years. Illustrator (prior to the CS crap), Photoshop and Acrobat are great, they work, they work well.

True. The recent improvements to Okular and Evince have made viewing pdfs on Linux really nice (for me anyways, and I have a ton of pdfs). Pages load fast, display nicely, and don't seriously tax my cpu, even on my slower, older, single core laptop. Some of these are the same pdfs that tax my faster (and with 3 times the memory) Windows XP desktop running Acrobat Reader.

Even with Foxit Reader viewing PDFs on Windows sucks compared to doing so on Linux or (especially!) Mac OS. You'd think by now that somebody would have come out with a Free-as-in-GPL viewing program that at least rivals Apple's Preview, but no...

(That reminds me, I need to see if Okular is stable and usable on KDE for Windows yet.)

Actually your right its not proprietary its been open... but has been for less than a year under ISO 32000... had to look it up since I avoid PDF... what you are talking about is PDF/A which is a watered down version...

I've written code that deals with PDF, both in terms of parsing and rendering it, as well as generating it. PDF is a great format. It certainly doesn't have the difficulties associated with, for instance, PostScript. Adobe's products might have poor performance but this is not due to the file format, which is NOT proprietary but actually quite well-documented.

I have no idea what sorts of crazy things happen inside Adobe's code. Suffice it to say, none of that is mandated by the PDF format.

I'm not sure there's any point to this, since the Red5 guys have already documented and implemented the protocol. And Wowza has a fantastic implementation, even though it's not open source. If nothing else, I'd like to see "Abobe" explains the fucked-up connection handshaking. "Send me any ol' 1500 bytes! Ok great, you're connected!"

The block of garbage at the beginning of the handshake is, as far as I can figure out, a bandwidth test. The pattern is intended to be resistant to compression, so as to more accurately measure the real throughput of the client's connection.

I think it's good that some companies, like Adobe, are realizing it makes good business sense to open up these protocols. However let's also be aware that Adobe is perfectly willing to tighten the screws further in other areas when they feel like THAT makes business sense. Anyone who (like me) uses any of their CS3 or CS4 products has dealt with this.

Actually, I should say the first install of CS3 or CS4 goes pretty well, and activation is painless. But if you've got it at home and at work - which is perfectly acceptable according to their EULA - then have a computer suddenly die, prepare to invest a lot of time in trying to get the licensing sorted out just so you can do your work.

So my (long-winded) point is: Good for Adobe, but let's not give them too much credit for this.

The chatroom should be in IRC or some other CHAT program that has been audited for security around CHATTING and any linkage should be done externally so that perhaps the PDF would load #pdfopen-word2008docs on irc.adobe.com in your IRC software, but embedding chat in a PDF is just silly.

I hate megavideo with their IP recording.
I hate the ones that use RTMP and don't let me download the flv file.
So now I need the freeware developers to update their firefox addons and freeware apps Greasemonkey scripts to support Adobe's or Abobe's (hahah) open specs on the RTMP.
I know orbit says it supports RTMP, but megavideo is impossible without getting your IP add changed.

Um, RTMP is not a chat protocol. It is a protocol for stateful connections with multiplexed streams for downloading large amounts of media with real-time responses and quality of service requirements. It is what the Flash Player uses to download audio and video from servers. See Wikipedia [wikipedia.org]. Next time, look up the topic before spouting off.