In Plex Media Player there are four different settings for Hardware decoding:
Enabled (modern hardware)
Enabled (older hardware)
Enabled (copy-back)
Disabled
I have searched but there doesn’t seem to be any explanation for what these different modes mean. The article about PMP settings (2016-12-03) only briefly explains what hardware decoding itself is. It would be good to know what type of hardware is considered modern and when it’s appropriate to use one of these settings over another
Also, they don’t seem to work. I have tried using all of them, restarting PMP in-between, and none of them seem to do anything on my machine. In the info window during playback, it always says “Hardware Decoding: no (videotoolbox)”. And I think hardware decoding is necessary, because some videos that in PHT plays 100 % smoothly and can skip ahead/back in instantaneously, in PMP drop a lot of frames if there is too much detail, and skipping usually means 5 seconds of loading for every step.
macOS 10.12.1, Plex Media Player 1.2.0.481-b45bbf24, MacBook Pro (13-inch, Early 2011)
Same for me - iMac (21.5", end 2012) and Mac Mini (mid 2010) - on the less powerful Mac Mini, I see tearing in the video, which is usually a sign that hardware decoding is not used
I looked in the logs, and I found the following error :
"2016-12-03 17:08:34 [ ERROR ] PlayerComponent.cpp @ 506 - vd: failed to init videotoolbox decoder: Hardware doesn’t support accelerated decoding for this stream or Videotoolbox decoder is not available at the moment (another application is using it). (-78) "
(on the iMac)
I looked through the mpv manual and tried setting different manual values for hwdec and vo in my mpv.conf file, but there was no difference. I also found this which I guess is related to the different settings I asked about in my original post?
–videotoolbox-format=
Set the internal pixel format used by --hwdec=videotoolbox on OSX. The choice of the format can influence performance considerably. On the other hand, there doesn’t appear to be a good way to detect the best format for the given hardware. nv12, the default, works better on modern hardware, while uyvy422 appears to be better for old hardware. rgb0 and yuv420p also work.
I see now that I also have the exact same line as bouscram above in my log file. And the next line in the log is:
2016-12-04 00:02:46 [ DEBUG ] PlayerComponent.cpp @ 500 - vd: Falling back to software decoding.
None of these modes should cause failure to use hw decoding - they just affect performance. The error you see seems to happen if e.g. a browser is using hw decoding, or (completely different situation) something about the file. This is pretty strange and I’ve seen it fail on OSX where it worked on Windows or Linux on exactly the same hardware. One user claim that the first playback works, but other playbacks after this show this error - this has to be investigated yet.
Anyway, here’s a detailed explanation for each mode:
Enabled (modern hardware)
This sets videotoolbox-format=nv12. It’s faster on modern OSX machines.
Enabled (older hardware)
This sets videotoolbox-format=uyvy422. We observed that this works much better for older HW, such as MacMinis from a few years ago. We suspect that if you use nv12, it will perform a slow conversion, which completely ruins performance. Unfortunately, we found no way to autodetect which format is ideal, so we made it a user option.
Enabled (copy-back)
This is like “Enabled (modern hardware)”, but copies the decoded video from GPU back to system memory. That’s an awfully technical explanation, which probably means you never need it. One thing it’s useful for is being able to enable deinterlacing, though.
This definitely needs to be investigated. I just did some testing on my iMac with all apps closed except PHT, hw decoding was not working… (also tested after rebooting, not working either…)
… So would it be fair to translate… we access the functions, give you choices for them, but really have no idea how they work or what hardware is best suited for each option…
When I think ‘detailed explanation’ … I dont think I have ever given one in a single line… in vagaries like ‘modern hardware’… care to embellish with chipset family, architecture, framebuffers, gpu memory, shader, etc units… that would be detailed…
What we have here is … try everything until you find one that ‘might’ work for you…
Or am I oversimplifying your overly simplistic answer…
Can you all provide the media info for a file that doesn’t hw-decode, and if available, a file that does hw-decode? For media info, the Plex XML would do, or the output of the mediainfo tool.
Sure. I’ve attached media info for a file that doesn’t hw-decode. I can’t supply anything else as there is no hw-decoding on anything. I can tell you though that the info for this file is pretty typical for my library.
Explanation: on my own machine it works for some files, but not others (all of those work under Windows and Linux on exactly the same machine). So I want to collect more information, and see what’s the difference between the working and broken cases.
I have started a thread here about the same issue:
Although hardware decoding does seem hit and miss across multiple machines (all different hardware) and multiple file types, I have only noticed actual video playback issues (stuttering and tearing) when using Angle, with an Nvidia GTX 1050 graphics card on recorded tv (.ts) files.
I am happy to provide more info / logs to help to get the issue resolved.
I would like to also report that on my Early 2015 Retina MacBook Pro, non of the Hardware Decoding options work (also tried forcing it in mpv.conf, with no luck). While playing back content, the Hardware Decoding comes with no videotoolbox message. Could be a limitation of the integrated Intel HD6100? Every 1080p BD Remux works fine with raw CPU usage, but 10bit HEVC playback (65Mbps+) starts to struggle, well no wonder if not even an i7 Quad Core can’t handle it without GPU help. But still no idea why hwdec doesn’t kick in, any news?
But I just tried a myriad of video files from my library and none of them had hw decoding on. However, all of my library is H264 so I can’t really try other codecs.
