Announcement

Collapse
No announcement yet.

VA-API's Libva 1.4.0 Brings VP8 Encoding Support

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

  • VA-API's Libva 1.4.0 Brings VP8 Encoding Support

    Phoronix: VA-API's Libva 1.4.0 Brings VP8 Encoding Support

    Intel's Haihao Xiang has announced the version 1.4.0 release of the VA-API library along with the company's updated VA-API driver...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Theoretical VP8 support only

    Theoretical VP8 support only. Existing hardware (Haswell) is not supported for VP8.

    Comment


    • #3
      This is VP8 and google is already working on VP10. Why do we need so many codecs? Is it really cheaper to develop your own codecs than just to obtain a license for H.264 and H.265? Even if they want their own codec, couldn't they just sit down, concentrate, think carefully and make one good codec instead of this VPx sequence?
      I'm still looking forward to Daala, from it's description it looks like they are using many novel features, would be interesting to see how it will compare to H.265 and google's VPn when it finally will be released.

      Comment


      • #4
        VP9

        Meh, no VP9 support.

        Comment


        • #5
          I wish I could use vaapi at least for any stuff. ON my Sandy bridge i5 system under fedora fc20 it seems impossible to get it running. normal mplayer does not support vaapi at all, if I got that right? mpv seems to be the fork that should support it, but cpu utulisation is at around 30% if I use xv or vaapi.

          Or is vaapi just very inefficiant?

          Comment


          • #6
            mplayer vaapi

            Originally posted by blackiwid View Post
            I wish I could use vaapi at least for any stuff. ON my Sandy bridge i5 system under fedora fc20 it seems impossible to get it running. normal mplayer does not support vaapi at all, if I got that right? mpv seems to be the fork that should support it, but cpu utulisation is at around 30% if I use xv or vaapi.

            Or is vaapi just very inefficiant?
            you need to install mplayer with vaapi, the normal one not works, use mpv or a backend to vdpau

            Comment


            • #7
              Originally posted by blackiwid View Post
              I wish I could use vaapi at least for any stuff. ON my Sandy bridge i5 system under fedora fc20 it seems impossible to get it running. normal mplayer does not support vaapi at all, if I got that right? mpv seems to be the fork that should support it, but cpu utulisation is at around 30% if I use xv or vaapi.

              Or is vaapi just very inefficiant?
              Assuming you've installed rpmfusion make sure you grab the rest of the vaapi gstreamer packages then you can just use totem.

              Comment


              • #8
                Originally posted by Szzz View Post
                This is VP8 and google is already working on VP10. Why do we need so many codecs? Is it really cheaper to develop your own codecs than just to obtain a license for H.264 and H.265? Even if they want their own codec, couldn't they just sit down, concentrate, think carefully and make one good codec instead of this VPx sequence?
                I'm still looking forward to Daala, from it's description it looks like they are using many novel features, would be interesting to see how it will compare to H.265 and google's VPn when it finally will be released.
                Basically people don't want to pay the fee, which can be substantial in certain circumstances (aiui, you don't just obtain a license but pay per use). However, you can just as easily ask why everyone doesn't use aac (which used to be the best codec). If they did we'd never have gotten opus.
                Daala is designed to compete against h.265+1, so it will be a few more years before it's ready.

                Comment


                • #9
                  Well this is certainly nice, especially if AMD is supporting VA-API.

                  Comment


                  • #10
                    Originally posted by blackiwid View Post
                    I wish I could use vaapi at least for any stuff. ON my Sandy bridge i5 system under fedora fc20 it seems impossible to get it running. normal mplayer does not support vaapi at all, if I got that right? mpv seems to be the fork that should support it, but cpu utulisation is at around 30% if I use xv or vaapi.

                    Or is vaapi just very inefficiant?
                    vaapi is actually quite good, much better then omx for now.

                    try:

                    mpv --vo=opengl --hwdec=vaapi <your video file here>

                    this should give you very low cpu usage (less then 5% on my i5-4200U / HD4400 running a full HD 1080p movie). its also fantastic for encoding, i can encode a full HD (1080p) 3h movie with transmageddon in around 15min tops.

                    Comment

                    Working...
                    X