Announcement

Collapse
No announcement yet.

AMD's UVD2-based XvBA Finally Does Something On Linux

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

  • That was the biggest fault - xvba was not released and then it was more or less obsolete as vdpau was introduced in most media players. So in theory the best would be a native vdpau implemention in fglrx.

    Comment


    • this time kano is right, you missed something.

      Comment


      • Originally posted by Kano View Post
        That was the biggest fault - xvba was not released and then it was more or less obsolete as vdpau was introduced in most media players. So in theory the best would be a native vdpau implemention in fglrx.
        XvBA *was* released to its target markets - embedded customers doing closed box implementations, and ISVs working on proprietary binary-only player apps.

        You just weren't part of those groups.
        Last edited by bridgman; 11-10-2009, 05:01 PM.

        Comment


        • Maybe on of the targets was Sony? But hiding a SDK does not make it better, just keeps it far away from lots of (free) testers.

          Comment


          • I can assure you that the decision to keep the API secret was not based on the hope that secrecy would make it "better".

            Comment


            • Apparently the decision also wasn't based on the goal of gaining wide adoption either.

              These are the problems with closed-source development - pretty much no one gets to know about what you've done, and even if they know it's there, pretty much no one benefits from it. And if the company priorities change and the closed-source offering is withdrawn, all of that work goes down the drain, never again to see the light of day. Having seen that already happen to the last 2 proprietary projects I worked on (more than 10 years ago now) I will never work on anything closed source ever again. There's no reward, just a waste of a few years hard work.

              Comment


              • Originally posted by highlandsun View Post
                Apparently the decision also wasn't based on the goal of gaining wide adoption either.
                That is correct. The goal was adoption in closed box embedded systems and proprietary player apps, not adoption by open source players.

                Comment


                • Well it could be the other way too - that not that many ppl see how much worse it is compared to vdpau

                  Comment


                  • Originally posted by Kano View Post
                    Well it could be the other way too - that not that many ppl see how much worse it is compared to vdpau
                    Depends on your definition of "worse". If it's going into embedded stuff, it will likely be very different and maybe not as suited to the pc. The reverse could also be true of vdpau.

                    Comment


                    • Well "embedded" could be bluray players. But even with those content i have examples with wrong color - vdpau shows em correctly. Maybe ATI wants to hide the Sony connection with that sdk - there are so many function names with deinterlacers or filters that it could not be just an coincidence.

                      Comment


                      • Originally posted by Kano View Post
                        Well "embedded" could be bluray players. But even with those content i have examples with wrong color - vdpau shows em correctly. Maybe ATI wants to hide the Sony connection with that sdk - there are so many function names with deinterlacers or filters that it could not be just an coincidence.
                        are you playing from a bluray player or from your pc?

                        Comment


                        • I play bluray content (m2ts) with mplayer vaapi - using xvba or vdpau backend (or pure vdpau in case or errors).

                          Comment


                          • Originally posted by Kano View Post
                            I play bluray content (m2ts) with mplayer vaapi - using xvba or vdpau backend (or pure vdpau in case or errors).
                            Well, then the case of embedded vs pc still stands.

                            Comment


                            • What's your definition of embedded? Basically it is a pc, it just does not look like one. xvba can be used with opengl output via xvba-video wrapper - that's nice to try, but it shows directly the limits.

                              a) The only known driver is 9-10 with working OpenGL output - and that driver is definitely broken.
                              b) OSD does only work without OpenGL output - but how to get that as long as the SDK is not available. Without OSD no subtiles are possible too - a very stupid restriction.

                              On a standard pc there are more possibilities than in a bluray player - there it only has to decode mpeg2 (which is not possible with mplayer vaapi), vc1 (works most of the time) and h264 l4.1 (it works in maybe 70% of all cases at max).

                              If you try other/non-standard h264 files then you can get everything from just rendering errors to complete driver lockup. That happended with vdpau too in the beginning, but now this is a really rare case. But compared even to the first vdpau enabled drivers it was much better than this 1 year old xvba!

                              Comment


                              • Originally posted by Kano View Post
                                What's your definition of embedded? Basically it is a pc, it just does not look like one.
                                As someone who works with embedded systems, I stopped reading your comment right there. Embedded systems are very different to a pc.

                                Comment

                                Working...
                                X