Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Graphics Security Software Upgrades Windows News Linux

Adobe Goes To Flash 10.1, Forgoes Security Fix For 10 320

An anonymous reader writes "The recent critical zero-day security flaw in Flash 10 may have fast-tracked the release of Flash 10.1 today. Adobe 10.1 boasts the much anticipated H.264 hardware acceleration. Except for Linux and Mac OS (PDF): 'Flash Player 10.1, H.264 hardware acceleration is not supported under Linux and Mac OS. Linux currently lacks a developed standard API that supports H.264 hardware video decoding, and Mac OS X does not expose access to the required APIs.' Your humble anonymous reporter, who is using Fedora Linux with a ATI IGP 340M, is very pleased that the developers of the OSS drivers have provided hardware acceleration for my GPU ('glxinfo : direct rendering: Yes,' 'OpenGL renderer string: Mesa DRI R100 (RS200 4337) 20090101 NO-TCL DRI2'), but even if Adobe did provide hardware acceleration for H.264 on Linux, they wouldn't provide it for me because they disable it for GPUs with SGI in the Client vendor string. Adobe 10.1, with all its goodness, now gives me around 95% CPU usage as opposed to about 75% with the previous release. Good times. I anticipate my Windows friends will have a much better experience."
This discussion has been archived. No new comments can be posted.

Adobe Goes To Flash 10.1, Forgoes Security Fix For 10

Comments Filter:
  • That's what they sound like, i.e., leaf blowers, when watching Flash video. It's welcome but Adobe/Macromedia should have done this *years* ago.

  • Apple provided APIs (Score:5, Informative)

    by ryanw ( 131814 ) on Thursday June 10, 2010 @07:07PM (#32529732)
    Apple has provided the API's [] to do the hardware decoding, and Adobe has a beta called Gala [] which has Mac OSX Hardware Acceleration enabled.. Adobe will have a release out soon that will incorporate the hardware decoding in OSX. My guess is Adobe had to fast-track the release of 10.1 to compensate for the wide open security holes they had lingering, and weren't prepared to merge the beta and the final release trees.
    • Re: (Score:3, Insightful)

      The worst part about this is Apple already had two APIs, QTKit and CoreAnimation, that could both do hardware accelerated H.264. Adobe bitched and moaned until they got low level access for no apparent reason.

      It seriously pissed me off every time Adobe whined about "no 3rd party H.264 support" on Mac. Apple even had several sessions at WWDC in years prior about how to enable it in your apps.

      • by washu_k ( 1628007 ) on Thursday June 10, 2010 @07:27PM (#32529980)
        No, the previous hardware acceleration APIs on OSX do NOT work. Check the problems VLC has had. Nothing except officially blessed Quicktime components could do H.264 acceleration on OSX until now despite Apple's claims. Even other plugins working through the Quicktime framework were denied access.

        Flash is a piece of crap, but lack of hardware acceleration on OSX is 100% Apple's fault, not Adobe's. Even if you hate Adobe/Flash this new API access is a good thing because VLC and the like now have working hardware acceleration as well.
        • No from what I can tell Adobe just hasn't used the standard APIs that Apple provided and at the same time complained that Apple didn't release the APIs.
          • by washu_k ( 1628007 ) on Thursday June 10, 2010 @07:45PM (#32530158)
            Then why didn't VLC, Mplayer, perrian etc use the official APIs? None of them had hardware acceleration on OSX either until this latest API release. Read up on the problem. The old APIs simply do not work.
    • Re: (Score:3, Informative)

      The whole hardware decoding was just a red herring anyways. Adobe is using this as an excuse as to why Flash on OS X sucks. The real problem for Adobe was that they wrote their own codecs instead of using Apple's APIs all this time. By doing so, any Flash content on Macs would require 100% CPU rendering instead of allowing the OS to use any available hardware like the GPU. I think the problem was that Adobe didn't move to the Cocoa framework which has these APIs but instead stayed on the Carbon framewor

      • by DigiShaman ( 671371 ) on Thursday June 10, 2010 @07:40PM (#32530110) Homepage

        Adobe is using this as an excuse as to why Flash on OS X sucks.

        See, I don't get it. I thought Adobe was begging Apple to get Flash on the iPhone. Why would they drop the ball on providing proper OS X support? What the hell is going on over at Adobe anyways?

        • Re: (Score:3, Insightful)

          I don't know because Adobe has been treating Apple like the red headed step child for many years focusing more on Windows than Linux or OS X. Even though roughly 50% of their CS suites are sold on OS X, they would rather focus on the Windows side of the business because that's where 90% of their Flash business is.
          • Re: (Score:2, Insightful)

            by Anonymous Coward

            ahhh ginger bashing - the last bastion of socially acceptable discrimination - if only there were more of us like the fags, niggers or gooks (see what i've done there to make the point)

        • See, I don't get it. I thought Adobe was begging Apple to get Flash on the iPhone. Why would they drop the ball on providing proper OS X support?

          Yeah, that one's lost on me, too. "Come on, Apple! Let us play on the iPad! I know we've been unable to deliver a non-half-assed OS X version in a decade, but this time it'll be different! I promise!" Will I completely understand and sympathize with the argument against walled gardens, Adobe's done absolutely nothing to help their case.

        • by nine-times ( 778537 ) <> on Thursday June 10, 2010 @08:33PM (#32530558) Homepage

          It's really pretty simple: Adobe doesn't want to make the investment necessary to make the Flash player efficient, stable, secure, and bloat-free. On the other hand, they want to keep making money selling the Flash development tools.

          So when Apple finally calls them on Flash's crappiness and starts pushing for standards, Adobe wages a PR war on Apple, including astroturfing to make it sound like techies and serious web developers all love Flash. Adobe claims they're just about to release some updates that will fix everything (and it doesn't matter if it's vaporware because it's all about PR) and tries to blame Apple for all of Flash's problems (even though it doesn't quite make sense).

          In reality, Flash has never been well supported on any platform except Windows. However, if Adobe admits to that, then a lot of their pro-Flash anti-HTML5 arguments fall apart. They're trying to sell Flash as being ubiquitous and platform-independent, but it isn't.

          • by bersl2 ( 689221 ) on Thursday June 10, 2010 @09:32PM (#32530870) Journal

            There need to be replacement development tools. There are many complex Flash animations which are worth watching, but the people who author them are not programmers, and they shouldn't need to be. I know there are SVG authoring tools, but do they work with animation?

            I want Flash dead as much as the next Slashdotter, but I'm not sure the development tools needed to replace Adobe's are there.

          • by Daltorak ( 122403 ) on Thursday June 10, 2010 @10:48PM (#32531272)

            It's really pretty simple: Adobe doesn't want to make the investment necessary to make the Flash player efficient, stable, secure, and bloat-free. On the other hand, they want to keep making money selling the Flash development tools.

            Excuse me, but.... huh?

            I'm going to assume you haven't actually researched this (i.e. "I went to the source and got the full story for myself" research and not just "I read a Slashdot comment once and got angry" research) and are just running at the mouth because you're angry, not because you're right.

            Which you aren't.

            Here, let me introduce you to a guy. His name is Tinic Uro, and he's one of the people who actually programs Flash. He's an engineer like us, not a marketing droid (or worse, an executive).

            Here are three blog entries you should fully familiarise yourself with before making any further comment on what Adobe is doing in terms of improving Flash on OS X.

            Flash 10.1 and Core Animation:
            (TL;DR: yes, Flash 10.1 uses Core Animation to accelerate overall Flash graphics performance -- not video specifically -- but you need OS X Snow Leopard and a super-new version of Safari)

            Flash 10.1 and timing:
            i>(TL;DR: They rebuilt the timer model in Flash 10.1 to use significantly less memory, however Safari on OS X is less flexible than other browsers when it comes to firing timer events, thus making video playback less smooth)

            H.264 hardware acceleration in OS X:
            (TL;DR: Adobe has released a post-10.1 beta version of Flash that supports full and proper video H.264 acceleration on Mac OS X, with the caveat that you have to have 10.6.3 and certain current graphics chips)

            The real story is this:

            Apple has been well behind Microsoft Windows when it comes to providing third parties with APIs to do hardware acceleration, and to do high-performing timer operations that are necessary to run browser plugins smoothly. I know the Slashdotterie will get all worked up over that assertion, but speaking as someone who's actually written browser plugin code, you'll just have to trust me on this. IE has always had the best timer support, which is one reason why video- or timeline-heavy plugins have always performed better than other platforms. As of OS X 10.6.3 and Safari 5, Apple has pretty much caught up.

            - Despite the headline-grabbing statements from Steve Jobs and other executive-types, there are actual hard-working developers at Apple and Adobe who actually collaborated to define a good API for high-performance video access for browser plugins. If Apple wasn't so deliriously secretive, you'd hear a lot more about it. Trouble is.... the only people who are allowed to blog at Apple are people who'll make the company look good and forward-thinking -- like the Webkit team.

            The problem with performance isn't 100% Adobe's fault. It can't be. Adobe's engineers aren't stupid -- if there had been an easy solution to good plugin video performance on the Mac all this time, they would've fixed it years ago. Why spend several years intentionally using a bad approach?

            Lastly.... despite what the article summary says here on Slashdot, overall Flash performance is quite a bit better in 10.1, especially on OS X. Do your own benchmarking; you'll see for yourself. It's still not as good as it should be, but it's a massive step forward. They know HTML5 is coming... they know they have to make Flash as good as or better than HTML5 or they'll be toast by 2020. They know all this.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        What bunch BS you are spreading. The Cocoa code migration problem is related to the desktop editing software like Photoshop and Illustrator. The Flash player code base is completely separate and have totally different issues. Most of them require changes in NPAPI and a lot of people at Adobe, Apple, Google and Opera are working on that as we speak. The other stupid comment you made about the codecs - how the hell you are supposed to call APIs that are not public? Apple just recently opened some of its inter

      • by christopherjs ( 456957 ) on Thursday June 10, 2010 @08:13PM (#32530370)

        I think the problem was that Adobe didn't move to the Cocoa framework which has these APIs but instead stayed on the Carbon framework which doesn't.

        This is why Steve Jobs called Adobe "lazy" as Cocoa and Carbon were first released back in 2001. Adobe before CS5 of this year didn't migrate their flagship products to Cocoa. That's nine years...

        Adobe is only slightly lazier than Apple themselves then, as Finder and quite a few other parts of OS X were still Carbon until Snow Leopard. That's eight years and they're the ones who developed the frameworks.

        • by prockcore ( 543967 ) on Thursday June 10, 2010 @09:28PM (#32530856)

          Many of their apps are still Carbon.

          Snow Leopard isn't 100% 64-bit, despite Apple's claims. Front Row, iTunes, Grapher, and DVD Player are all still 32-bit apps. That's because they are written in C++/Carbon instead of ObjC/Cocoa. Apple has had how long to rewrite them?

        • by Sycraft-fu ( 314770 ) on Thursday June 10, 2010 @10:13PM (#32531088)

          Also you can argue developers have a bit of a right to be lazy, and cross with Apple. Apple thrust a lot of changes on them, and has changed their mind on various things a number of times (like the no 64-bit Carbon when it was originally promised). They were asking people to do a lot of extra work, and you can understand devs might get angry. Especially when there's MS who seems to bend over backwards to try and make things easy and compatible. Now they don't always succeed, nobody but a fanboy would call them perfect, but they do put forth a good effort. Their 64-bit setup was very much designed to provide easy compatibility. The APIs were extremely similar, etc. So a 64-bit port shouldn't be too much work (unless you did things like cast pointers to 32-bit ints or whatnot).

          While I'm not saying Adboe is blameless here, you can't lay all the blame at their feet either. Apple has gone through a bunch of changes, starting with OS-X itself and including some major things like a total architecture switch. That generates a lot of extra work.

          There's also the fact that Cocoa is all Objective-C. Doesn't matter if you like it or not, it is something developers are not nearly as familiar with. So there's relearning there, plus additional recoding. While cross platform ports will always take a good bit of recoding, if you are having to change languages that just makes it take all the more. So I can understand why they'd want to stick with C++ and Cocoa since that would make it less work in terms of porting with Windows.

    • Re: (Score:3, Informative)

      by ravenspear ( 756059 )
      Ok I tested that beta but it only gives about a 2x speedup.

      If I look at my cpu while viewing my company's homepage which has a large flash animation, I get the following results on OS X (imac 27" 4x core i7).

      10.0: around 150% (1.5 cores)
      10.1: around 75-80%

      So, while an improvement this hardware acceleration doesn't really change the fact that flash on the Mac still sucks. It shouldn't take 80% of your CPU just to view a webpage.
      • Re: (Score:3, Insightful)

        by ryanw ( 131814 )

        Does your company's homepage have a flash animation or H.264 video? The acceleration is only for H.264 hardware decoding. There is no acceleration for use of adobe's proprietary animations.

  • by Just Some Guy ( 3352 ) <> on Thursday June 10, 2010 @07:08PM (#32529744) Homepage Journal

    Linux currently lacks a developed standard API that supports H.264 hardware video decoding, and Mac OS X does not expose access to the required APIs.

    The Linux thing might be true. Even if there was one universally implemented GL desktop standard, that's not the same as having a universally implemented hardware decoding API. They're pretty much orthogonal. As far as OS X, though, nothing changes the fact that Flash uses 3x as much CPU as VLC to render the same video []. Spare me the apologist line of "Flash does more work than VLC!" - maybe that's their whole problem. You'd think something as widely used would have some optimized codepaths for the most common use case of playing Youtube videos.

    • Re: (Score:3, Informative)

      But flash does more work than VLC! For instance, if you right-click on your VLC window, do you get an "About Adobe Flash Player XX..." option? Didn't think so. You'd be surprised how many CPU cycles that little bugger eats up.
    • by JamesP ( 688957 )

      It seems linux has a standart API, but it's quite recent: It's called VDPAU

      • Re: (Score:2, Informative)

        by Anonymous Coward
        It's a little more complicated than that. VDPAU is Nvidia's solution to the problem. The "new standard" is called VA-API, and is supported natively by Intel and S3 for some of their chipsets. It can also use the proprietary VDPAU (Nvidia) and XvBA (AMD/ATI) driver extensions as backends.
    • Thats because flash isnt using hardware acceleration but VLC is.

      • I don't think that's true. From my (admittedly limited) understanding, VLC is software-only. Either way, it's ludicrous that an open source project can get decent video performance while Adobe can't.

    • by Per Wigren ( 5315 ) on Thursday June 10, 2010 @08:16PM (#32530404) Homepage
      Linux has VA-API [], the one true standard for hardware accelerated video decoding on Linux. Adobe should just use that and not struggle with the various proprietary vendor-specific APIs (VDPAU, XvBA, etc).
  • by thestudio_bob ( 894258 ) on Thursday June 10, 2010 @07:09PM (#32529764)

    and Mac OS X does not expose access to the required APIs.

    Apple recently added an official API to access the H.264 decoding features of certain NVIDIA GPUs used in recent Macs. I'm sure Adobe was just rushing to get this out because of the zero-day.

    Adobe will accelerate Flash video using new Apple API []

  • by innocent_white_lamb ( 151825 ) on Thursday June 10, 2010 @07:11PM (#32529794)

    No more 64-bit Linux version: []

    The Flash Player 10.1 64-bit Linux beta is closed. We remain committed to delivering 64-bit support in a future release of Flash Player. No further information is available at this time.

    • by WrongSizeGlass ( 838941 ) on Thursday June 10, 2010 @07:26PM (#32529956)
      They closed the 64-bit Linux beta ... but didn't release a 64-bit Linux version of 10.1? So they closed the beta but not the security hole? Rocket surgery indeed!

      Quidquid latine dictum sit, altum viditur.

      He who speaks Latin is doomed to repeat it?

    • by Fnkmaster ( 89084 ) on Thursday June 10, 2010 @07:39PM (#32530104)

      The old 10.0.45 version of it appears to still be downloadable from here [] (not sure if there was another version after that).

      However, given the rate at which security issues crop up in Flash, you are probably better off using the nspluginwrapper thunking stuff or other method for your distro that makes the 32 bit plugin work on 64 bit Linux, rather than running an out of date Flash plugin.

      • by gmack ( 197796 ) <.ten.erifrenni. .ta. .kcamg.> on Thursday June 10, 2010 @08:00PM (#32530264) Homepage Journal

        nspluginwrapper is not only unstable but it blocks keyboard input to flash. Using it is a complete waste of time.

        Better off pressuring websites to dump flash.

        • Never heard of that one. Keyboard input always worked fine for me and plenty other people, though there was a problem with mouse input with a one-time workaround. I've been running 64-bit for a while now, but if Adobe is not fixing the security hole in the 64bit version, I guess I'll have to go back to nspluginwrapper. At least until YouTube reliably works in Firefox without Flash.

        • by bersl2 ( 689221 ) on Thursday June 10, 2010 @09:20PM (#32530836) Journal

          Better off pressuring websites to dump flash.

          While it would please me to no end for everyone to dump Flash in favor of HTML5+SVG+SMIL/Javascript, the fact is that one or more pieces of software needs to be written to replace the Flash authoring tools. There are many SVG programs, but those don't do everything needed.

    • Re: (Score:3, Insightful)

      by macemoneta ( 154740 )

      With the pressure from HTML5 and Apple, I guess Adobe figures now is a good time to fragment the Flash market. We no longer need Flash for Youtube, and we'll just have to suffer through not having dancing, blaring, advertisements. Strangely, I'm OK with this.

      • by IANAAC ( 692242 )

        We no longer need Flash for Youtube...

        There are a fair number of us that have never needed Youtube, but would love to see an alternative for things like Hulu.

  • Let's kill Flash (Score:3, Insightful)

    by MrEricSir ( 398214 ) on Thursday June 10, 2010 @07:19PM (#32529874) Homepage

    Next time I see a commercial website that requires Flash, I'll call the vendor and explain why I can't use their website. Should help kill Flash once and for all.

  • That's good (Score:2, Insightful)

    by blai ( 1380673 )
    The less people with hardware-accelerated Flash, the less people would use flash, right?
  • by Nahor ( 41537 ) on Thursday June 10, 2010 @07:20PM (#32529896)

    "Direct rendering" != "Hardware acceleration".

    Correct me if I'm wrong but:
    - "Direct rendering" = decode the data directly to Video buffer. Otherwise the data needs to be decoded to a RAM buffer which then needs to be copied to the Video buffer to be actually displayed.
    - "Hardware acceleration" = use the GPU for decoding (because a GPU is usually way faster than the CPU for this kind of work).

    So you can have "direct rendering" without the "hardware acceleration" (and vice-versa though it's unlikely to happen in practice).

    • Also (Score:5, Informative)

      by Sycraft-fu ( 314770 ) on Thursday June 10, 2010 @07:25PM (#32529940)

      Acceleration of H.264 is different than OpenGL acceleration. You can have a card with full GL acceleration that doesn't accelerate H.264 decoding. Indeed many older cards were like this. The original GeForce 8800s didn't have full H.264 acceleration, despite their massive amount of 3D hardware.

      You have a separate API for that sort of thing, and near as I know Linux does not provide that. You could still implement it, of course, by implementing the lower level stuff needed to talk to the card in the correct way, but that is rather a lot of work and not really the place of a user mode app. Idea is the OS should provide the APIs/ABIs for that sort of thing. Driver makers then support it on the low end, apps plug in on the high end and it all works.

  • by Foofoobar ( 318279 ) on Thursday June 10, 2010 @07:29PM (#32529994)

    I anticipate my Windows friends will have a much better experience


  • Download Links (Score:5, Informative)

    by Anonymous Coward on Thursday June 10, 2010 @07:30PM (#32530000)

    If you don't like the 'Adobe Downloader', use this page:

  • by ptbarnett ( 159784 ) on Thursday June 10, 2010 @07:41PM (#32530122)

    Adobe Goes to Flash 10.1

    "These go to eleven." []

  • No mac or linux HW support? I call Shenanigans on Adobe!

    Can we get our brooms now?

  • by h4rr4r ( 612664 ) on Thursday June 10, 2010 @08:24PM (#32530480)

    So then why does Gnash have hardware acceleration?

    Seems to me it is more likely the folks that can't even make a 64 bit client are the problem here.

  • by batkiwi ( 137781 ) on Thursday June 10, 2010 @09:46PM (#32530958) []

    Nvidia's wildly successful VDPAU implements VaAPI, as does:
    -intel GMA500
    -radeon UVD2

  • by Peganthyrus ( 713645 ) on Friday June 11, 2010 @11:46AM (#32536338) Homepage

    So I download the .dmg and open it and run the installer.

    The "Install" button's ghosted out until I click the "I have read and agree to the terms of the license agreement" checkbox. But where's the agreement? Well, there's a link (with no rollover state, of course) to this page on Adobe's site [], with a bewilderingly-long list of links to EULAs. As PDFs.

    Nobody ever reads the EULA anyway, but this is ridiculous.

"If you lived today as if it were your last, you'd buy up a box of rockets and fire them all off, wouldn't you?" -- Garrison Keillor