Announcement

Collapse
No announcement yet.

AMD Lands OpenMAX State Tracker In Mesa Gallium3D

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

  • #11
    Originally posted by mrugiero View Post
    Right, I misread the Gov part as being them imposing restrictions signaled to those articles (which I didn't look up for), instead of imposing those to the Gov. Anyway, the restriction is only recognition? If that's so, is pretty much as free for them as whatever license (MIT, right?) mesa uses.
    Yeah, here's the links i used:

    http://www.law.cornell.edu/cfr/text/48/252.227-7013

    http://www.gpo.gov/fdsys/pkg/CFR-201...c52-227-14.pdf

    It just sees like a lot of definitions of terms used within government contractors and probably some disclaimers along the lines that the US Gov doesn't own this software that they are using and so they dont have the power to license it out or claim patents or anything like that.

    It seems more along the lines of restricting government usage rather than end user joe-schmo / john smith usage
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #12
      If one is not a contract law expert for corporations, please stop conjecturing on what is or is not a legal position. It gets tiresome, real quick.

      Comment


      • #13
        Originally posted by Ericg View Post
        Hey Alex, personal opinion as well as paid developer opinion: is the over all plan to settle on strictly OpenMAX since its basically OpenGL but for video encode/decode, and eventually dump VDPAU, or are you guys just gonna try to keep both in lockstep and just tell everyone "Support Gstreamer or support VDPAU, just pick one."
        VDPAU is still our primary recommendation for desktop video decoding. The OpenMAX state tracker is mostly for VCE bringup and to better support GStreamer.

        Originally posted by Ericg View Post
        On the one hand, VDPAU is the most used and stable Video API we've got on Linux at the moment. But on the other hand, it would be nice to just tell developers "Use the Khronos API's and you'll be fine, Linux follows Khronos." So that they can just follow one platform-independent standard.
        Correct yes. Appart from that the output of OpenMAX for H264 is an elementary stream, so it was just a good fit for our hardware.

        Originally posted by Ericg View Post
        Followup: Any plans to help Handbrake along to support VCE? I know they're pushing towards using Intel QuickSync so this would be a nice offset
        We don't really have the resources for that, sorry.

        Christian.

        Comment


        • #14
          Originally posted by Marc Driftmeyer View Post
          If one is not a contract law expert for corporations, please stop conjecturing on what is or is not a legal position. It gets tiresome, real quick.
          If such conjecture is tiring you, perhaps you should avoid reading it, rather than telling others to stop writing it.

          Comment


          • #15
            Originally posted by Ericg View Post
            Followup: Any plans to help Handbrake along to support VCE? I know they're pushing towards using Intel QuickSync so this would be a nice offset
            I was under the impression that handbreak was a graphical front end for x264/ffmpeg and that the easiest way to support this would be to add support to the underlying binary. Enabling it in Handbreak would be as easy as adding a checkbox or a custom CLI parameter.

            No?

            F

            Comment


            • #16
              Originally posted by Deathsimple View Post
              VDPAU is still our primary recommendation for desktop video decoding. The OpenMAX state tracker is mostly for VCE bringup and to better support GStreamer.



              Correct yes. Appart from that the output of OpenMAX for H264 is an elementary stream, so it was just a good fit for our hardware.



              We don't really have the resources for that, sorry.

              Christian.
              Thanks for the reply, Christian.

              I know VDPAU handles decode and presentation, but does it also have the API to support encoding as well? I've never heard of encoding through VDPAU, but maybe I just missed it somewhere.

              Unfortunate to hear about Handbrake, but hopefully they wont have any problems supporting it pretty quickly.

              Cheers.
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #17
                Originally posted by Ericg View Post
                Thanks for the reply, Christian.

                I know VDPAU handles decode and presentation, but does it also have the API to support encoding as well? I've never heard of encoding through VDPAU, but maybe I just missed it somewhere.

                Unfortunate to hear about Handbrake, but hopefully they wont have any problems supporting it pretty quickly.

                Cheers.
                If I recall correctly, someone from AMD submitted a VA-API state tracker (probably resurected the removed one) for Mesa some time before first version of OpenMax one, but it seems nobody cared enough for it. If Radeon drivers expose UVD through VA-API (or is it the other way arround?) you could use VA-API for encoding.

                Comment


                • #18
                  Originally posted by orzel View Post
                  Ok, then, how is that useful ? Does mplayer/mpv/xine or anything can make use of it ? Anybody knows how this "State tracker" is visible to the outside world ?
                  Android uses OpenMAX.

                  Comment


                  • #19
                    Originally posted by Article
                    to eventually support video acceleration and also in providing H.264 Hi10P decode support that wasn't offered in VDPAU.
                    I keep trying to find a comprehensive source for whatever progress the radeon devs have actually made towards this, but other than the handful of mailing list posts back in October, I've not been able to find anything.

                    Has anyone been able to actually use this to decode Hi10P content, with some sort of proof (screenshots, etc.)? Something thorough and hard, rather than the vague "someone's trying it out", or "someone reckoned that ultimately it didn't work"?

                    Comment


                    • #20
                      Originally posted by droidhacker View Post
                      Android uses OpenMAX.
                      Oh, that's interesting.
                      Though... i have never heard of any AMD chip used with android... is there any ? Or maybe it was not used because of this openmax support missing and AMD kinda fill the gap ?

                      Comment

                      Working...
                      X