Announcement

Collapse
No announcement yet.

AMD Releases Open-Source VCE 1.0 Support

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

  • AMD Releases Open-Source VCE 1.0 Support

    Phoronix: AMD Releases Open-Source VCE 1.0 Support

    AMD has gone back and managed to provide open-source Linux users with support for the VCE 1.0 video encode engine...

    http://www.phoronix.com/scan.php?pag...Source-VCE-1.0

  • #2
    Thats awesome but for me useless ... The most important framework for me (ffmpeg), don't support openmax but Intel quick sync and nvidias nvdec and nvenc on windows and Linux ...

    this is also annoying, because the rpi also use openmax for the encoder

    Comment


    • #3
      Originally posted by Nille View Post
      Thats awesome but for me useless ... The most important framework for me (ffmpeg), don't support openmax but Intel quick sync and nvidias nvdec and nvenc on windows and Linux ...

      this is also annoying, because the rpi also use openmax for the encoder
      I thought it was mainly to benefit AMD stuff, not the Raspberry Pi's ARM stuff.

      Comment


      • #4
        Awesome, now i need to make my custom kernel to test this, openmax is not a problem for me tho

        As always AMD TYVM, now my r9-280 just became perfect

        Comment


        • #5
          Originally posted by profoundWHALE View Post

          I thought it was mainly to benefit AMD stuff, not the Raspberry Pi's ARM stuff.
          OpenMax is the Open[GL|CL] of video decoding, not an AMD solution. Its main use right now is in mobile, but I for one hope it'll get more support. With opemMax being in Mesa, all video drivers could quite easily implement it.

          Serafean

          Comment


          • #6
            Originally posted by Serafean View Post

            OpenMax is the Open[GL|CL] of video decoding, not an AMD solution. Its main use right now is in mobile, but I for one hope it'll get more support. With opemMax being in Mesa, all video drivers could quite easily implement it.

            Serafean
            It will be nice if we can have ONE solution. So far we have VDAPU (which somehow works with vaapi) and VAAPI which last time i tried was giving me a green screen with gst.

            Comment


            • #7
              Originally posted by 89c51 View Post

              It will be nice if we can have ONE solution. So far we have VDAPU (which somehow works with vaapi) and VAAPI which last time i tried was giving me a green screen with gst.
              VDPAU is decode only. This is talking about ENCODING support.

              Comment


              • #8
                Originally posted by 89c51 View Post

                It will be nice if we can have ONE solution. So far we have VDAPU (which somehow works with vaapi) and VAAPI which last time i tried was giving me a green screen with gst.
                well vaapi is working perfectly for me, it doesnt work by default tho but i think is not mesa fault

                you need to export this variable in /etc/enviroment

                export LIBVA_DRIVER_NAME=gallium need a recent mesa tho

                Comment


                • #9
                  Thanks AMD and Christian K?nig for this.

                  Comment


                  • #10
                    Originally posted by profoundWHALE View Post
                    I thought it was mainly to benefit AMD stuff, not the Raspberry Pi's ARM stuff.
                    My rant was target to the situation. We now have support for all VCE Encoders but the api is not used by the framework. We have the same situation on the rpi with the encoder. on the other hand, there is support for intels and nvidias own apis in this framework.
                    Last edited by Nille; 12 May 2015, 01:50 PM.

                    Comment

                    Working...
                    X