Announcement

Collapse
No announcement yet.

Adobe's Linux Video API Rant Extended

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    When playing video, the "RGB elements" could be converted to YUV. This would have to happen only once and then this whole argument of "flash being a different problem" falls flat on its ass.

    Your bog-standard video player can do OSD and subtitles. This is done in by superimposing YUV on the frames. Not by converting the YUV frame to RGB and then superimposing in RGB.

    This YUV argument is plain false or misleading at best.

    Comment


    • #17
      Originally posted by gbeauche View Post
      The other claims are wrong too. All Linux drivers but IEGD offer a means to get decoded frames out of the GPU. VA-API and VDPAU are both suitable in a way to avoid this retrieval of decoded frames (VA subpictures / VDPAU layers). The concepts for that are rather simple, but the implementation is probably a little less trivial depending on the vector graphics rendering engine used.
      Are you the guy working for splitted desktop systems that
      s given us vaapi support for libavcodec and gnash and the vaapi wrappers for xvba and vdpau? If so thanks for your work.

      Your comment (quoted below) with real measured numbers speaks a hell of a lot more than mike m.

      "But minority browsers don't use as much CPU while playing HTML5 video tag data.

      Are you sure about that?"

      Safari 4.0.4 running in 32-bit mode under Mac OS X 10.6.2, on an iMac with a 2.16 Ghz Intel Core 2 Duo and 3GB of RAM.

      Using http://www.youtube.com/watch?v=1AwvuirSEAA and viewing the 720p version sized to 960 pixels wide (the larger size in the browser window), streaming.

      Using Flash Plugin, 100-115% CPU (105% typical). (!!!)

      Using Quicktime Plugin (that's in the browser via Click2Flash), 30% - 40% CPU (35% typical).

      Unfortunately YouTube's HTML5 beta doesn't appear to work with anyhing but standard def videos (I can't get it to work with that video anyway). So, with http://www.youtube.com/watch?v=mEIZ_FFmjnw

      Using Flash Plugin, 65-70% CPU.

      Using Quicktime Plugin, 15-20% CPU.

      Using HTML5, 15-20% CPU.

      Pesky facts."

      Thanks for your work and calling him out on the lies.

      Comment


      • #18
        Thank you Michael for such a well constructed rant. Rather enjoyable.

        Comment


        • #19
          Originally posted by sreyan View Post
          Your comment (quoted below) with real measured numbers speaks a hell of a lot more than mike m.

          "But minority browsers don't use as much CPU while playing HTML5 video tag data.

          Are you sure about that?"
          <--snip--->
          Pesky facts."

          Thanks for your work and calling him out on the lies.

          I got a chuckle out of that too, heck even moonlight offers far lower resource usage then flash playing back HD media. At least the Olympic coverage isn't using flash.

          Comment


          • #20
            In the end some of Melanson's claims are justified, but in the end..
            LOL @ "In the end...but in the end.."

            Adobe can be doing much more -- without investing too much -- to improving their Flash Player support on Linux.
            .. but it's far easier to post FUD about Linux inferiority in a blog and expect moneyed interests and your entrenched market position to justify doing the bare minimum to support your product on Linux. When "pesky facts" arise, be sure to paint your opponents as freetards or even better, hippies.

            Comment


            • #21
              I would not be to hard on the guy.

              All the different mix of video APIs is a bad thing.

              There is, indeed, many places that Linux video falls behind when compared to Windows.

              And, yes, Flash is doing lots of things that other applications are not. This is because it's a very complex way of doing things... mostly a bad idea way of doing things, but very complex non-the-less.

              But I'd take html5-based video over flash-based video anyday.

              Comment


              • #22
                yuv

                Yea.... lots of things can overlay over video (subtitles?) using x-video, not sure I understand why flash can't.

                Comment


                • #23
                  Originally posted by StringCheesian View Post
                  He's ranting but so are you. I think this should have been an editorial rather than a news article.
                  Not only that. If Michael would have looked up who Mike is, he would have known that Mike is one of the main developers behind FFmpeg, the video encoding/decoding library that drives all the FOSS video player (and many things more). Not to mention that Mike reverse engineered VP3 which eventually led to development of Theora.

                  So Mike knows exactly what he is talking about, he knows what a video player is, he knows what the problems with in designing fast video applications are and where Linux lacks behind Windows and where it's far beyond.

                  To take the claims apart that this article/editorial says are so outragous:

                  Converting YUV to RGB is a huge task. It can easily use up as much performance as the decoding process itself. If you dont believe it, just try something like
                  Code:
                  mplayer -benchmark -vf format=rgb24
                  and compare the playback speed (yes, MPlayers format conversion routines are highly optimized, so they are about as fast as you can get).

                  I dont see where Mike claims that any of the APIs on Linux aren't fully implemented yet. Neither where he claims that Adobe has any weight within the industry to force chip manufacturers to implement drivers. I think the author has not read the article and just assumes things after skimming over it.

                  But to put it here straight: The available hardware video decoding APIs on linux ALL SUCK! Why? Because they were designed by people who write graphics card drivers and express what they think is important. Nobody ever asked the guys who develop video players what they actually need or what would help them. It was just assumed that this or that is enough for them to write fast players. And this way of development started as early as Xvideo (compare it to the interface mga_vid or vidix provide, which are both older, and see for yourself how complicated XV is to use). All those that came afterwards XvMC, VA API, VDPAU, XvBA are the same. Designed for nice looking driver code, not for fast playing systems.

                  The claim that Crystal HD is read for production use goes in the same category. It might be ready for someone who knows how to hack around a system, who is used to upgrade his applications when he upgrades a driver or to wait a few weeks until his favorite application is updated. But for a company that delivers a binary, heck even for a distribution, Crystal HD is not ready yet! Just because there are some patches around does not mean that Joe Average can use it already.

                  In the end this article is just a huge rant with half informed guesses by someone who has a very RMS-like world view and doesn't see much into the problems of video player development. Comming from this restricted world view and judging other people who work in a totaly different field is more than just questionable.

                  Comment


                  • #24
                    I read the second blog post as primarily a response to the questions which basically said "other players have done it, why can't Flash". I don't think there was any intention of saying that the need to blend in RGB was stopping Adobe from providing a solution, just that it was more difficult than tossing encoded video into an API's VLD entry point, which *is* an option for most players.

                    AFAICS Mike is saying that they need APIs which will allow player code to sit between the decode and render operations. As Gwenole pointed out, both the ATI and NVidia implementations have a mechanism to do this (not sure about VA-API), however there are "more differences" between the vendor's implementations of *that* style of playback than between the VLD entry points.

                    I didn't think blending in YCbCr was really practical, unless the blending algorithm essentially converted to RGB on the fly, blended, then converted back.

                    Part of the problem, I guess, is that Flash is an extremely powerful and versatile tool, but one of its most common applications is playing back video in a rectangle on a white background. That scenario uses about 5% of Flash's capabilities, but I suspect the issue is that the developers need to make sure the other 95% work as well -- and *that's* where things become difficult.

                    Comment


                    • #25
                      Originally posted by KotH View Post
                      Converting YUV to RGB is a huge task.
                      isn't that just a simple per-pixel matrix multiplication, i.e. a trivial task for any shader-based GPU? If the YUV image is already in video memory, why can't it be converted there before moving it to GPU space for manual blending?

                      Comment


                      • #26
                        It's cheap on a GPU if the YCbCr image is in video memory and you want the result in video memory as well, fairly expensive on a CPU, and moderately expensive on a GPU if you want the result back in system memory so the CPU can chew on it some more.

                        I don't know what the specific requirements are for Flash, ie whether the decoded image needs to be further processed on the CPU or just via GPU operations using GL. I suspect the requirement is for CPU processing, since AFAIK post-decode processing using GL is already being done by Adobe and other players.

                        Comment


                        • #27
                          Originally posted by jdeslip View Post
                          this is the most unprofessional article I have ever read on Phoronix.
                          You must be new here...

                          Comment


                          • #28
                            Colorspace Conversion: Isn't it simple to have 50MB of RAM reserved for YUV -> RGB conversion lookup table, for users that have no HW acceleration, but have plenty (well, 50MB) of RAM? This table can be shared in RAM for all running video encoding/decoding instances. In such table you can simply define RGB for each YUV combination and have image converted in no time.

                            Scaling: How is scaling a problem? Did Second Reality demo scaled a bold guy's face in full screen on 486 back in Ronald Reagan era? Yes, it also used look-up table, you don't have to calculate everything all the time. For video scaled to 1920x1080 screen (size of source image is not important), you need only 8MB lookup table. Again, conversion is done in no time.

                            Can somebody enlighten me why things that were simple in late eighties are complicated and _slow_ again on more then 100x times faster CPUs?

                            Comment


                            • #29
                              my comment on the Adobe penguin blog still awaits moderation for the last 12 hours or so.

                              i've just asked why Adobe did not ask about/for those needed API changes in the nVidia Linux drivers while their teams worked on the Windows Flash 10.1 and 19x.xx integration.

                              i find it hard to believe that while working at that no one said "hey guys maybe we/you can do that on Linux & Mac too since our/your driver core shares 90% or whatever of the code"

                              Comment


                              • #30
                                Originally posted by DanL View Post
                                When "pesky facts" arise, be sure to paint your opponents as freetards or even better, hippies.
                                or communists

                                Comment

                                Working...
                                X