Enable hardware video decoding by default in mpv

[Daniel van Vugt]

Enable hardware video decoding by default.

Upstream doesn't do this, supposedly because the quality is lower. However that concern if justified at all, is only valid for low quality videos. I don't think it's a good enough reason to use orders of magnitude more CPU...

All we need is one line in: /etc/mpv/mpv.conf
 hwdec = auto

[Daniel van Vugt (vanvugt)]

Probably need to wait for the pending release first:
 mpv (0.26.0-3) unstable; urgency=medium

[Daniel van Vugt (vanvugt)]

I will/should try to remember to patch mpv for bug 1698287 at the same time as this.

[Daniel van Vugt (vanvugt)]

Here's the fix. Working hardware acceleration out-of-the-box, in Wayland and Xorg.

[Launchpad Janitor (janitor)]

This bug was fixed in the package mpv - 0.26.0-3ubuntu1

---------------
mpv (0.26.0-3ubuntu1) artful; urgency=medium

  * Prefer Wayland over X11, so if both are present (e.g. Xwayland) then
    VA-API gets a display type that works (LP: #1698287)
  * Enable hardware acceleration by default (LP: #1708102)

 -- Daniel van Vugt <email address hidden> Wed, 09 Aug 2017 16:38:55 +0800

[Martin Herkt (lachs0r)]

Could you explain to me why you did not ask upstream about this? There are reasons for these defaults, and this is likely going to flood our issue tracker. Is this how Ubuntu maintains packages in general? Just fuck upstream and change defaults because one user thinks he knows better?

[Daniel van Vugt (vanvugt)]

That is not true. The platform order fix was proposed to upstream 6 weeks before it was applied to Ubuntu:
  https://github.com/mpv-player/mpv/pull/4556
At the time the only reason given for upstream not liking it was that native wayland surfaces lack title bars. That's not good enough reason to deny users working video acceleration out of the box.

As for enabling acceleration by default, that's a goal of the desktop team for 17.10. According to the default config in the source:

# Enable hardware decoding if available. Often, this does not work with all
# video outputs, but should work well with default settings on most systems.
# If performance or energy usage is an issue, forcing the vdpau or vaapi VOs
# may or may not help.
#hwdec=auto

So the decision to use it depends on the outputs and general performance. For the outputs we have verified it works well on both X11 and Wayland. For the performance, we have verified that hwdec with VAAPI provides an order of magnitude improvement. So it meets our goals. In fact, mpv+hwdec is presently the only player that can compete with the efficiency other platforms like macOS.

We would like to keep being able to recommend mpv as the optimal player. However if Ubuntu was forced to disable acceleration out of the box we would need to withdraw that recommendation because editing config files is not sufficiently user friendly.

Of course, if users did complain about the state of mpv in Ubuntu then we would consider their input. For the moment though there are zero recent bug reports:
  https://bugs.launchpad.net/ubuntu/+source/mpv

[Martin Herkt (lachs0r)]

Re hwdec:
https://git.srsfckn.biz/mpv/commit/?id=dbef5b737e2f994f02923c8214cba368b663a655

Also, off the top of my head:
- vaapi-egl does not work on AMD hardware AFAIK, breaking hwdec on Wayland and resulting in low-quality or incorrect color conversion when vaapi-glx is used
- VDPAU does not support 10-bit video (and 8-bit HEVC is buggy with NVIDIA drivers), is generally broken with FOSS drivers
- CUDA decoding is just broken in general
- there’s this gem https://github.com/mpv-player/mpv/issues/4383
- video filtering does not work with non-copy hwdec

Also, at least in my testing, I’ve noticed no energy savings when using hwdec, on both desktop (measuring at the wall) and my laptops (according to PowerTOP). Nobody ever bothered to extend the comments in the default config after all those issues that were encountered. Perhaps I should do that.

If you *really* want to enable hwdec despite all that, at least restrict it to the “safer” -copy modes by using auto-copy.

Re Wayland:
- video-sync=display-resample is unavailable with the Wayland backend, which also breaks interpolation (a very popular feature to reduce judder)
- Wayland support in mpv is not mature by any stretch, plus we have less than one person available to work on it regularly

[Daniel van Vugt (vanvugt)]

Thanks for that.

My focus for the past couple of months has been specifically on VAAPI for Intel HD graphics. That is stable and performs very well too. Intel HD graphics is important because that covers the vast majority of our users.

As an example, with a UHD test video I get CPU usage of:
  hwdec=vaapi 5%
  hwdec=vaapi-copy 40%
  hwdec=no 300%

So yes, vaapi works remarkably well. I have not measured how that translates to watts but the other benefit of using VAAPI is that videos previously unplayably slow on many machines (UHD and particularly HEVC) are now actually playable and smooth.

In order to avoid most of the issues you mention though, I think we should constrain the default config at install time to just:

  if (only one GPU and it is handled by i915) then install:
    hwdec=vaapi
  else
    hwdec=no
  endif

I don't want to step on the toes of non-Intel users. However equally I don't want to diminish the great experience we've achieved for users with just Intel GPUs.

Anyone remaining who does install mpv and continues to experience problems can get around them with:
  echo "hwdec=no" > ~/.config/mpv/mpv.conf
I'm happy to monitor the bugs etc and advise people so.

[Adrien Nader (adrien)]

Hey Daniel, the diff is still present. Do you have a different opinion on the matter now? I have "hwdec=auto-safe" locally (but that's also intel hardware).

[Daniel van Vugt (vanvugt)]

If hwdec=auto-safe works the same as vaapi on supported hardware then it sounds like we could use it. But:

1. I haven't tested it. I'll flag this for testing later; and

2. Nobody is reporting mpv bugs to us on this subject so it would be poor engineering discipline to change something not known to be broken.