mpv
mpv copied to clipboard
mpv-player
issues with hardwaredecoding of h265
Important Information
- mpv version: 0.33.0-184-g03b9f8e323
- Windows Version: Windows 10 21H1 and pretty much any earlier version of Windows 10
- Source of the mpv binary: shinchiro builds
- Video card and drivers: Intel HD520, all tested drivers since the issue started, also "known good" drivers that worked before
- affected mpv versions: all tested versions since over a year were affected
Reproduction steps
Play pretty much any h265-encoded video file, enable hardware acceleration and maybe seek around a bit in the video.
Expected behavior
Videos should play normally, mpv should stay responsive, in case of driver hiccups at least "recover" and allow for a graceful shutdown.
Actual behavior
I've observed several outcomes without any clear pattern.
- More often than not mpv just straight up freezes.
- Sometimes a file can be played for a while without any apparent issue. Trying to seek, switch to fullscreen or resize the window often results in a freeze.
- Sometimes audio continues to play in the background, sometimes not.
- Sometimes there is is a message in the logs, which reads:
[vo/gpu/d3d11] Failed to create Texture2D, but that does not always happen! - Sometimes mpv continues to eat up a whole CPU core while playing dead, sometimes it does not.
Disabling hardware decoding via hotkey doesn't work either in this state. The only way to recover is to kill mpv using some sort of task manager on Windows. Ever since the issues started, I disabled hardware decoding for h265 and then everything just works fine. I know you (used to?) advice against hardware decoding, still there seems to be something at fault and worthy to report. h264, vp9 and everything else I threw at mpv work like a charm with (and without, if not available) hardware acceleration.
Log file
A log can be found here: https://bin.disroot.org/?50bb3a475c449723#EZTmcxzHVxEPktE95wZWTMNHx3iiFfTaE7cNTBdMeyXg Note that I tried to resize the mpv window before killing mpv. This was to show that mpv was still somehow "alive" (producing logs) but not responding to any hotkeys or other mouse actions.
If you need any more information, I'll try to provide them. Thank you!
I'm not found (maybe I missed it) a clear Intel explanation about h265 decoding for all their hardware. http://wp.xin.at/archives/3561
Sell your old hardware then upgrade to the new one :( (No idea)
It's Intel's fault.Full support of hevc needs Kabylake or after iGPU(HD Graphics 6xx) Same behavior on Haswell&Broadwell iGPUs.
It's Intel's fault.Full support of hevc needs Kabylake or after iGPU(HD Graphics 6xx) Same behavior on Haswell&Broadwell iGPUs.
Uhm - what do you mean by "full support". Skylake suppots (should support) 8bit h265 decode and encode according to multiple sources. Intel says it does, Wikipedia says it does and even ffmpeg's wiki says it does. Kabylake adds h265 encode according to ffmpeg which seems to have nothing to do with the issue at hand. Haswell and Broadwell seem to lack h265-support entirely so I am not quite sure where you are coming from with your claim.
At any rate if there is no support, I'd expect mpv (or ffmpeg or whatever puzzle piece is to be blamed) to politely say "no" instead of randomly and inconsistently crash and burn. Do not get me wrong - I do not expect hardware acceleration to be a given and I understand it might be iffy at times. Still I'd prefer mpv to gracefully handle hiccups and/or produce some useful log output and not just die or freeze. If h265 on Skylake and prior is officialy broken, which does not seem to be the case, then maybe remove support entirely.
https://mpv.io/manual/stable/#video
As an example for something that still causes problems: certain combinations of HEVC and Intel chips on Windows tend to cause mpv to crash, most likely due to driver bugs.
Relevant quote:
auto-safe is similar to auto, but allows only whitelisted methods that are considered "safe". This is supposed to be a reasonable way to enable hardware decdoding by default in a config file (even though you shouldn't do that anyway; prefer runtime enabling with Ctrl+h). Unlike auto, this will not try to enable unknown or known-to-be-bad methods. In addition, this may disable hardware decoding in other situations when it's known to cause problems, but currently this mechanism is quite primitive. (As an example for something that still causes problems: certain combinations of HEVC and Intel chips on Windows tend to cause mpv to crash, most likely due to driver bugs.)
auto-safe does enable hardware decoding for me and it does randomly die. So if you are to blame Intel and if you state that auto-safe is a reasonable choice, then I'd expect mpv not to die and just default to software decoding in this case. You cannot claim that intel+hevc is known to be bad and still default to hardware decoding when choosing a "reasonable" and "safe" option. Either it really is Intel's fault (I have no clue..) in which case auto-safe should pick a safe option (e.g. potential improvement/bug on mpv's side) or it is not Intel's fault. In this case and there is a bug somewhere else.
On a side note: dxva2 did work in a quick test just now while d3d11va did not. But do not consider this conclusive. I experimented with different options in the past and there are issues/drawbacks with almost all of them. d3d11va worked best in the majority of cases but it really does not with most h265 encodes. At least not for me.
About 7~8years ago,Intel claimed that its HD graphics could decode HEVC through "hybrid decode".But later they deleted relevant statements on their website.Based on my test with Broadwell/Haswell CPUs,mpv works with DXVA2 on HEVC samples.However,using dxva2 can result in wrong color.
So my conclusion is that Intel found their "hybrid decode" was a failure,but they didn't fix their drvier(maby they tried,but the result is a broken d3d11va api) but to fix their website description.
Recent discovery. On Windows8.1,mpv hwdec=d3d11va plays hevc samples without crash. GPU:HD grahics 5500
The OP is a bit old and there's been a lot of hardware decoding changes since then. Feel free to make new issues for anything specific here if they still persist.
The OP is a bit old and there's been a lot of hardware decoding changes since then. Feel free to make new issues for anything specific here if they still persist.
In a quick test, pretty much nothing changed for me. I tested v0.36.0-50-g67292855, built 3 days ago.
I didn't look into details and cannot confirm every single detail I described earlier, but at first glance, the issues persist more or less unchanged. Shall we just reopen this issue or should I indeed create a new one?