VA-API's Libva 1.4.0 Brings VP8 Encoding Support

[liam]

Using totem and gstreamer1-vaapi for Tears of Steel @4k (video bitrate ~74000kbps) results in totem using no more than 10%, and usually around 8%.
i7-3520m on f20

[blackiwid]

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.

thank you for that hints, why the hell is there vaapi listed if I type in mpv --vo help:

[black@mars ~]$ mpv --vo help
Available video outputs:
vdpau : VDPAU with X11
opengl : Extended OpenGL Renderer
xv : X11/Xv
opengl-old : OpenGL (legacy VO, may work better on older GPUs)
vaapi : VA API with X11

Why giving there the option vaapi when its not working with va=vaapi.

To the gstreamer hint, yes its nice I think vdpau does not work with gstreamer/totem so nice to have that option, but at the moment I use gnome-mplayer and somethimes smplayer. So I would have to port my youtube-functions in emacs for that, and I am not so shure if I really like the interface.

Am using i3wm anyway so there totem makes not soooo good experience I think.

ok testet mpv with that options and cpu load did decrease from 20-30% to 7-10% on the same video.

[Gusar]

thank you for that hints, why the hell is there vaapi listed if I type in mpv --vo help:

There are two parts to video playback - decoding and presentation. The --hwdec options controls the former, the --vo option controls the latter. Then there's opengl interoperability. So you can use either --vo=vaapi or --vo=opengl(-hq). The vaapi vo is resource efficient, but not very feature rich. The opengl vo contains many features that provide a better picture (in particular, complex scalers), but this stresses the GPU more. But whatever the vo, you need to specify --hwdec=vaapi for hardware decoding.

[blackiwid]

There are two parts to video playback - decoding and presentation. The --hwdec options controls the former, the --vo option controls the latter. Then there's opengl interoperability. So you can use either --vo=vaapi or --vo=opengl(-hq). The vaapi vo is resource efficient, but not very feature rich. The opengl vo contains many features that provide a better picture (in particular, complex scalers), but this stresses the GPU more. But whatever the vo, you need to specify --hwdec=vaapi for hardware decoding.

And why do I then not need --hwdec=vdpau to use vdpau and have less cpu utilisation? I mean I had big cpu load advantages with vo vdpau alone, but none with vo vaapi? (the vdpau example was with amd apu)

[Gusar]

And why do I then not need --hwdec=vdpau to use vdpau and have less cpu utilisation?

Of course you do. VDPAU = Video Decode and Presentation API for UNIX. Two parts, just like with VAAPI.

I mean I had big cpu load advantages with vo vdpau alone, but none with vo vaapi? (the vdpau example was with amd apu)

Maybe there was no Xv support for your particular GPU at that time, so mpv was using the non-accelerated X11 output, and switching to --vo=vdpau gave you accelerated presentation. That's the only explanation that makes sense.

[blackiwid]

Of course you do. VDPAU = Video Decode and Presentation API for UNIX. Two parts, just like with VAAPI.

Maybe there was no Xv support for your particular GPU at that time, so mpv was using the non-accelerated X11 output, and switching to --vo=vdpau gave you accelerated presentation. That's the only explanation that makes sense.

xv support for zacate should be pretty old or not?

[Gusar]

xv support for zacate should be pretty old or not?

I would think so. No idea what you were observing then. The hwdec option defaults to "no" (meaning software decoding), without changing that to "auto" or "vdpau" there's shouldn't be a significant difference in CPU usage between Xv and vdpau presentation. Unless Zacate has a really crappy Xv implementation.

[blackiwid]

I would think so. No idea what you were observing then. The hwdec option defaults to "no" (meaning software decoding), without changing that to "auto" or "vdpau" there's shouldn't be a significant difference in CPU usage between Xv and vdpau presentation. Unless Zacate has a really crappy Xv implementation.

either that, or it has something to do with the smplayer and gnome-mplayer guis. As example I see there a option under video-module "activate video-hardware-accelleration" I dont think I explizitlity activated that, but maybe it does that dependend on the output module u have selected.

But I did the initial testing to get vdpau running with mplayer on the console, and I saw bigger differences. I had more than 100% cpu load (2 cores) somethimes with xv and dont know maybe 30% with vdpau. So I thought I activated gpu-accelleration or gpu encoding.

its pretty anoying that the players dont use that as default, it has huge advantages and no or only small disadvantages. But I cant even choose hwdec stuff from a dropdown. I have to use "further parameters" field to set it with the command line switch.

Its pretty anoying that this all is so bad under linux, I also dont get why the hell mplayer does not support vaapi and if this project is kind of dead why not change default installation in all distros to mpv. Or is that a patent issue?

gnome-mplayer does not even start when I select mpv as mplayer (incompatible parameters I guess).

[Gusar]

The hwdec option is mpv specific, mplayer and mplayer2 have a different way to enable hardware decoding. And if GUIs are in play, the only way to know what exactly is going on is to check ps to see how the underlying player was launched. Without that, it's impossible to know what exactly the state of your machine was when you did your tests.

Also, mpv dropped the "slave mode" from mplayer/mplayer2, that's why no GUI designed for those will work with mpv. With mpv you either use its built-in OSC (on-screen controller) or someone will write a GUI using libmpv, mpv's client library.