Visible corruption when playing VP9 in mpv --hwdec=vaapi
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| mpv (Ubuntu) |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
Hi friends. I'd like to share some findings. These have included the 17.10 repo version of MPV (v0.26) as well as a more recent PPA version (v0.27). Behaviors have been the same between the two versions. This is using VAAPI hardware acceleration. My processor is an i5-7200u. My system is Ubuntu 17.10. I'm using the Wayland session.
mpv.conf:
gpu-context=wayland
hwdec=vaapi
vo=gpu
save-position-
The issue comes in when streaming certain videos online. I was finding some videos would work fine, yet others would present a lot of gray box-like artifacts, enough where visibility of the video was impossible. I began to pay more attention to the terminal output when launching mpv + youtube.com URL via CLI. After some searching about video codecs, I began to wonder if the issue was specific to VP9 videos.
jason@JasT470:~$ mpv https:/
Driver 'opengl' has been replaced with 'gpu'!
Driver 'opengl' has been replaced with 'gpu'!
Resuming playback. This behavior can be disabled with --no-resume-
Loading config '/home/
Playing: https:/
(+) Video --vid=1 (*) (vp9 1920x1080 29.970fps)
(+) Audio --aid=1 --alang=eng (*) 'DASH audio' (opus 2ch 48000Hz) (external)
AO: [pulse] 48000Hz stereo 2ch float
Using hardware decoding (vaapi).
VO: [gpu] 1920x1080 vaapi[nv12]
AV: 00:00:26 / 00:03:26 (12%) A-V: 0.000 Cache: 10s+23MB
Saving state.
The above resulted in video that looks like the attached image. At times the video would seemingly buffer enough and work, though most of the time it looked like that image. Even when it would clear up a little bit, any sort of seeking would instigate the gray to overtake the majority of the player window again. During this time I experienced no issues with audio when the video was playing.
After doing some digging and finding some discussion regarding folks wanting to avoid VP9 (but not having much context as to why), a string to pass in mpv.conf was provided as follows:
ytdl-format=
After appending this to my mpv.conf, I re-ran the same video as I did above.
jason@JasT470:~$ mpv https:/
Driver 'opengl' has been replaced with 'gpu'!
Driver 'opengl' has been replaced with 'gpu'!
Resuming playback. This behavior can be disabled with --no-resume-
Loading config '/home/
Playing: https:/
(+) Video --vid=1 (*) (h264 1920x1080 29.970fps)
(+) Audio --aid=1 --alang=eng (*) 'DASH audio' (opus 2ch 48000Hz) (external)
AO: [pulse] 48000Hz stereo 2ch float
Using hardware decoding (vaapi).
VO: [gpu] 1920x1080 vaapi[nv12]
AV: 00:00:07 / 00:03:26 (3%) A-V: 0.000 Cache: 10s+25MB
Saving state.
As you can see in this second output (yet sourcing the same YouTube video), h264 is used in place of VP9. In this case, I had no video artifacts whatsoever, leading me to suspect the issue may be isolated around the VP9 codec.
Please let me know if I can be of any assistance with testing. Thank you for your time!
| JaSauders (jasauders) wrote | #1 |
| Daniel van Vugt (vanvugt) wrote | #2 |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in mpv (Ubuntu): | |
| status: | New → Confirmed |
| Changed in mpv (Ubuntu): | |
| importance: | Undecided → Medium |
| summary: |
- Issue streaming VP9 based videos with MPV in 17.10 with VAAPI hardware - accel in Wayland session + Visible corruption when playing VP9 in mpv --hwdec=vaapi |
Sorry for the delay...
Bug confirmed. And confirmed it's only in "mpv --hwdec=vaapi". So another workaround is to use hwdec=no. But that's not as good as your workaround of using "ytdl-format" to retain hardware acceleration via H.264.
I have also verified that the VP9 video stream is good. You can verify this using hwdec=no or by downloading the video and playing it with something else like mplayer or totem. They all play the webm/VP9 video file perfectly.
Interestingly users of older CPUs probably won't hit this problem. Seems that MPV is smart enough to not even try to download VP9 for them and will automatically get the H.264 instead.
Please log the bug upstream: https:/