Forgot your password?
typodupeerror
Communications Programming IT Technology

Adobe To Open Real-Time Messaging Protocol 108

Posted by timothy
from the after-jabber dept.
synodinos writes "Adobe has announced plans to publish the Real-Time Messaging Protocol specification, which is designed for high-performance transmission of audio, video, and data between Adobe Flash Platform technologies. This move that has followed the opening of the AMF spec has been received with varying degrees of enthusiasm from the RIA community."
This discussion has been archived. No new comments can be posted.

Adobe To Open Real-Time Messaging Protocol

Comments Filter:
  • Who are... (Score:3, Funny)

    by Anonymous Coward on Thursday January 22, 2009 @03:03PM (#26563605)
    ..."Abobe"?!
  • I wonder if the RIAA will be as enthusiastic too..
  • Please? Can someone fix the topic?

    Bad Timothy!

  • haXe (Score:3, Insightful)

    by plams (744927) on Thursday January 22, 2009 @03:11PM (#26563719) Homepage
    This is good news for the haXe community [haxe.org].
    • by ianare (1132971)
      why?
      • by plams (744927)
        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.
  • when have they developed anything with peformance in mind ??? I wish I could stab PDFs in thier proprietry format face!
    • Re: (Score:2, Insightful)

      PDF isn't a proprietary format. It's ISO 19005-1:2005
      • Re:Adobe (Score:5, Interesting)

        by SanityInAnarchy (655584) <ninja@slaphack.com> on Thursday January 22, 2009 @03:26PM (#26564027) Journal

        Which proves two things:

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

        • by Arterion (941661)

          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

        • Re: (Score:3, Interesting)

          by Andy Dodd (701)

          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.

          • by Elbows (208758)

            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.

            • Re: (Score:3, Informative)

              by daveime (1253762)

              HTTPHeaders can be as useful as anything else.

              It will list the full URL of every html, image, css, js, and flv requested from the server for the current page.

              Simply copy the flv URL and paste stright back into the browser ... instant save-as prompt and your done :-)

              • by Andy Dodd (701)

                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

          • s/hulu/iplayer for me.

          • Yeah.
            I've a system with the same CPU. Hulu's fullscreen videos are horribly slow. The same video "regular size" is okay most of the time.

            This video is impossible to watch in HD on the Athlon XP system:
            http://www.youtube.com/watch?v=4pXfHLUlZf4 [youtube.com]
            Though it's just fine on my laptop. (Core Duo L2400 @ 1.66GHz) Straaange.

        • by mhall119 (1035984)

          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.

        • by Futil3 (931900)
          VLC can do hardware acceleration. The Flash Player can not. (with some exceptions [kaourantin.net])
          • VLC can do hardware acceleration. The Flash Player can not.

            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

            • Embed the video directly with that object tag

              THIS! (For everything but cellphones, I guess.)

              • Or just HTML5 video tag. Even if the iPhone doesn't already support it, Safari does (using QuickTime), so it doesn't seem wholly unlikely that iPhone Safari (using iPhone QucikTime) would support it.

                That gets you Safari and Firefox, and it seems likely other browsers (Chrome, Konqueror, etc) will follow.

                If that fails -- and it should be possible to gracefully detect that failure, which I think is not necessarily true with an object tag -- fall back to Flash and/or object tags.

                • Or just HTML5 video tag.

                  Aye. I didn't mention it 'cause HTML5 isn't yet supported in a stable release of any browser that I know of.

                  Also, go check the latest W3C doc about the video and audio tags. They have a bit of a mismatch WRT their "hypothetical users" and application support.

                  • Aye. I didn't mention it 'cause HTML5 isn't yet supported in a stable release of any browser that I know of.

                    Safari.

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

        • by thatbox (868467)
          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.
      • by Anonymous Coward
        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.
      • There's not really anything that inherently makes PDF slow, either. Adobe Acrobat and Acrobat Reader happen to be pretty boated, but the format can be rendered fairly quickly.

        • Re: (Score:2, Insightful)

          by nextekcarl (1402899)
          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.
          • Re:Adobe (Score:4, Informative)

            by DMUTPeregrine (612791) on Thursday January 22, 2009 @04:18PM (#26564975) Journal
            On windows, try Foxit Reader. If you must stick with acrobat reader, disable all the plug-ins you don't need. They massively increase the loading time.
            • Oh, thanks. That looks pretty nice.
            • 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.)

        • by powerlord (28156)

          Exactly.

          Preview.app on OS X, or Foxit Software's Foxit Reader [foxitsoftware.com] for Windows are both examples of lightweight PDF viewers that render pretty darn quick.

          I'm sure there must be one for Linux, but hey, we all use the CLI there right? ;)

      • 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...
      • How about "when have they developed something with security in mind"? Maybe I'm just bitter, but it seems like every week there's another handful of flash and acrobat exploits.
    • by GenP (686381)
      At least PDFs are guaranteed to render in finite time.
    • Re:Adobe (Score:4, Informative)

      by pclminion (145572) on Thursday January 22, 2009 @05:48PM (#26566347)

      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.

  • Whew... By reading the topic alone, I thought someone "great! someone just reinvented IRC..."
  • by RobTerrell (139316) on Thursday January 22, 2009 @03:40PM (#26564297) Homepage

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

    • Seriously, right? And get this- I did ask their techs directly if their RTMPE format was a truly encrypted stream of data and not just the handshake- yes yes they assured me. Nice.

      Remember RIA is a term THEY made up so bullshit artists could speak bullshit to one another.

    • Re: (Score:2, Informative)

      by bwb (6483)

      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.

  • Good news, but... (Score:3, Insightful)

    by 93 Escort Wagon (326346) on Thursday January 22, 2009 @03:43PM (#26564341)

    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.

  • by Conspiracy_Of_Doves (236787) on Thursday January 22, 2009 @04:24PM (#26565079)

    ...embed a chat room in a PDF and talk to anyone who has a copy of the same PDF open.

  • The bloat goes in before the name goes on.
  • by manoj91 (1007629)
    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.

The meat is rotten, but the booze is holding out. Computer translation of "The spirit is willing, but the flesh is weak."

Working...