Announcement

Collapse
No announcement yet.

Vulkan Video Arrives For New Industry-Standard Video Encode/Decode

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

  • #21
    correct me if I'm wrong, but my understanding of this is that it's just a gateway using Vulkan two GPUs pre-existing video engine. I do not believe this will add any extra functionality to cards. RX 580s will not magically get VP9 or AV1 decoding, raspberry Pi's will not magically get hardware accelerated decoding either.

    I could be wrong. but just reading briefly on the site. (I could have missed something) it doesn't seem like vulkan itself will do the decoding.

    Comment


    • #22
      i remember that mpv has Vulkan backend

      what is different ?

      Comment


      • #23
        Originally posted by Aryma View Post
        i remember that mpv has Vulkan backend

        what is different ?
        They use vulkan for rendering the onscreen image. not for encode/decode

        Comment


        • #24
          Originally posted by Quackdoc View Post
          correct me if I'm wrong, but my understanding of this is that it's just a gateway using Vulkan two GPUs pre-existing video engine. I do not believe this will add any extra functionality to cards. RX 580s will not magically get VP9 or AV1 decoding, raspberry Pi's will not magically get hardware accelerated decoding either.

          I could be wrong. but just reading briefly on the site. (I could have missed something) it doesn't seem like vulkan itself will do the decoding.
          Correct. These extensions are roughly equivalent to existing APIs like OpenMAX or VA-API. They just expose the video encode/decode engines on the GPU via the Vulkan API.

          Comment


          • #25
            Originally posted by M@yeulC View Post

            But why would you actually want AMF instead of VA-API or directly using this vulkan API?

            Going forward, I expect there will be a VAAPI<->Vulkan bridge pretty soon.
            On my 5600xt, vaapi encode quality for h264 really sucks, compared to amf.
            I manly use quality based encoding and vaapi produces 25% bigger files to achieve the same quality of amf.
            Luckilly one can keep installed radv and amf togheter and switch on the fly.


            Comment


            • #26
              Originally posted by agd5f View Post
              Correct. These extensions are roughly equivalent to existing APIs like OpenMAX or VA-API. They just expose the video encode/decode engines on the GPU via the Vulkan API.
              Really I wonder if this is going to be done right or will be another screw up like OpenMAX and VA-API.

              There is a basic problem. From what you have said I expect it going to be another screw-up. Remember video encode/decode engines on GPU are not all created equal.

              If this new one is truly going to be implemented under Vulkan cannot the API be provide by hardware video encode/decode or a Vulkan layer saying use cpu software rendering or GPU compute units instead of the hardware.

              There has been a repeating problem. It is make these API/ABI only to expose hardware video decoding so application developers have to use some other interface when hardware acceleration is not there and users in case of hardware acceleration of video not working right cannot override effectively.

              This is the reality
              1) applications really need 1 API for video playback and encode that works well in all cases so not needing to either use extra abstraction layer increasing dependencies and bugs or use 2 API to deal with the problem of hardware video accelerator being there or not being there or not working right. .
              2) end users need control if application is using the hardware accelerated video playback or is using cpu or is using gpu compute units. Due to the differences in quality and speed between those 3 options. The vuklan layers system does mean this time around this would be possible to implement.
              3) open tracking of where development is for the public that is easy to find. mesamatrix you look that and it does not tell you how much OpenMAX or VA-API is implemented.

              OpenMAX and VA-API at this stage does not deliver what is need. If there is not a different thinking this time this will be just another lemon.

              Comment


              • #27
                Originally posted by oiaohm View Post

                Really I wonder if this is going to be done right or will be another screw up like OpenMAX and VA-API.

                There is a basic problem. From what you have said I expect it going to be another screw-up. Remember video encode/decode engines on GPU are not all created equal.

                If this new one is truly going to be implemented under Vulkan cannot the API be provide by hardware video encode/decode or a Vulkan layer saying use cpu software rendering or GPU compute units instead of the hardware.

                There has been a repeating problem. It is make these API/ABI only to expose hardware video decoding so application developers have to use some other interface when hardware acceleration is not there and users in case of hardware acceleration of video not working right cannot override effectively.

                This is the reality
                1) applications really need 1 API for video playback and encode that works well in all cases so not needing to either use extra abstraction layer increasing dependencies and bugs or use 2 API to deal with the problem of hardware video accelerator being there or not being there or not working right. .
                2) end users need control if application is using the hardware accelerated video playback or is using cpu or is using gpu compute units. Due to the differences in quality and speed between those 3 options. The vuklan layers system does mean this time around this would be possible to implement.
                3) open tracking of where development is for the public that is easy to find. mesamatrix you look that and it does not tell you how much OpenMAX or VA-API is implemented.

                OpenMAX and VA-API at this stage does not deliver what is need. If there is not a different thinking this time this will be just another lemon.
                Whether an app is using GPU encode/decode or software is irrelevant to the vulkan interface from my understanding. choosing between software vs hardware will be as it always is. nothing will change here, nor do I really see a need to.

                This shouldn't be thought of as a VAAPI replacement alone. I see the strengths here. if you are an application developer, assuming hardware support. This should be completely cross-platform. It will replace VAAPI for Linux, openmax/libstagefright on android AND dxgi(? I honestly can't remember the name of it right now. I think it's that though) on windows in one fell swoop. remeber how long it took vaapi on linux webbrowsers? hopefully stuff like that will be a thing of the past... assuming this does as decent a job of vaapi, and an okay job compared to dxgi.

                Do not blame poor coding on VAAPI and openmax it is not VAAPI's job to implement software decoding. it is the application developers. Vulkan-Video already had a potential user base. I highly doubt it will end up as a lemon.

                EDIT:Not DXGI, DXVA, I should not comment right before I go to bed
                Last edited by Quackdoc; 14 April 2021, 01:48 PM. Reason: Correction

                Comment


                • #28
                  3 pages of comments and no one has posted the XKCD Standards comic? you nerds are slipping!

                  Comment


                  • #29
                    Originally posted by dc_coder_84 View Post
                    And VAAPI is using OpenGL for now?
                    No it is using either GLX or DRM directly.

                    Comment


                    • #30
                      How to know which GPus are involved by this innovation?

                      Comment

                      Working...
                      X