By comparison, with the new patches a 24 FPS HD video that ran choppy with a CPU load of over 100% (8% total) now runs fluently at half the load (50% MPV and 4% total). 60 FPS HD video still has a pretty high CPU load (over 100% MPV) but runs without problems. There is still a bit of frame dropping occasionally but that seems to happen when something overlays the video, like the seeking bar or the dock. Haven't tested subtitles yet. But for now, I'm just happy this is fixed!
Original post below.
I'd like to put together some information I have collected regarding the issue of stuttering/choppy video playback (and missing video hardware acceleration) on AMD hackintoshes. I too face this problem ever since I started running macOS on Ryzen.
I hope that AMD users who do NOT have this problem can give some feedback in this thread, especially about the hardware they are using (is it a problem with the X platform, Nvidia cards, etc.?)
I've been using an old Sandy Bridge system as my daily macOS machine for two years. Video playback was never an issue. Now I built a new machine with these specs:
MSI X570 Gaming Carbon motherboard
2x 8 GB DDR4-3200 RAM (G.Skill Trident Z)
I'm currently using an Nvidia GeForce GT 730 for macOS. My primary GPU is the new Radeon RX 5700 XT (Navi architecture), and I hope that Apple will support this card sooner or later. For now, the GT 730 does the job in macOS. The Radeon card is identified by macOS as "Display" but not used.
I used the same GT 730 in the Sandy Bridge machine, by the way. So I'm only comparing platform and CPU.
I have tested a fresh install of macOS 10.14.6 (Vanilla with Clover "live" kernel patches) as well as booting my old 10.13.6 SSD that came from the Sandy Bridge machine. The issue is the same on both. It is not exclusive to Mojave.
To make sure my GPU is not limited because it might be "unsupported" by Apple, I tested OpenGL capabilities by running QuakeSpasm and YamagiQuake2. Both run flawlessly on the hardware. macOS's UI is also running smoothly. As you will see further down, the GPU can also decode video, just not in ffmpeg-based applications.
ffmpeg-based video players such as MPV (my main player of choice), VLC, IINA and Kodi stutter heavily even with SD H.264 video. HD and 60 FPS video is extremely choppy. In my case, audio is always running fine and timing is okay too, but framerates are atriocious.
This does NOT affect QuickTime, Safari or even Firefox. All videos play absolutely fine with these. It DOES affect Chrome since Google does not allow hardware acceleration for video playback on Chrome. The other programs can and do use hardware decoding.
TL;DR: CPU load is extremely high and seems to overload the CPU. Also, hardware video decoding is unavailable.
Hardware decoding of video (i.e. using the GPU to assist playback) is handled by the API VideoToolbox on macOS. However, a video decoder must gain access to the API to use hardware acceleration.
Chrome and ffmpeg are apparently denied the usage of hardware video decoding and have to fall back to pure CPU-based (software) decoding. This happens on both Intel and AMD systems, so is not a hardware issue. You can see evidence of it in the MPV log file (parameter is "--log-file=<FILE>") and by checking Activity Monitor for the presence of "VTDecoderXPCService". If the service is NOT present while video is running, or if the service is not using any CPU, then that means hardware decoding is not used. Everything is decoded by the CPU.
Now, MPV for example does not use hardware decoding by default (you have to force it via parameter "--hwdec=auto") and on Intel systems this isn't a problem since CPU load is pretty low even at 1080p 60 FPS. So you could say that ffmpeg *should* be running fine in software; it was designed that way. The issue is two-fold:
1) the AMD CPU is overloaded by software decoding and cannot efficiently decode video
2) hardware-assisted decoding is unavailable, which could serve as a workaround for issue #1
To prove that #1 is related to macOS and not the hardware, I tested MPV on Windows where it decoded a 60 FPS video at 1080p with a CPU usage of under 2%! Forcing hardware decoding works and lowers CPU usage to <1%.
In macOS I see over 130% for the same video. An SD video with 25 FPS uses 80%. Both stutter heavily. I realize that macOS measures CPU load differently so "100%" does not mean full load on all cores. But in comparison, the same 60 FPS video on my Sandy Bridge machine uses about "30%" (and that's a quad-core) while running smoothly.
Other people have reported this problem, for example:
People have suggested that the bus ratio must be set correctly, however this affects audio-video timing more than stuttering. I have correctly set bus ratio and CPU frequency in Clover's config file and nothing changed at all.
Shaneee suggested that AMD's version of "Turbo Boost" can cause the issue and suggested disabling it. No change. Even disabling SMT ("HyperThreading") does nothing.
I suspected general slow CPU performance, so I tested Geekbench in Windows and macOS. I got better scores in macOS! And since the OS runs smoothly and boots very quickly off my SATA SSD, I can't fault that either.
My theory is that ffmpeg has a 'bug' of sorts that prevents it from accessing all the fast instruction sets in the AMD CPU, but only under macOS. It might be an issue that will never be fixed because AMD hackintoshes are such a niche thing.
The question now would be, how do we enable hardware video decoding to get around the issue? Is it even possible? Since QuickTime and browser video do use hardware decoding and run fine, it would be prudent to find a way to get that to run in ffmpeg players too.
Lastly, before someone suggests to "just use QuickTime": the reason we are trying to use MPV/VLC is that QuickTime has little to no support for specific containers (advanced MP4 containers, MKV and others) and can't display subtitles either, among other things.
Intel systems running macOS have no problem decoding video in software since CPU load is low. AMD systems using vanilla patching methods run fine but are overloaded by software video decoding. ffmpeg can't use hardware decoding for some reason (on Intel systems as well; it's a macOS issue) which would solve the problem. QuickTime and browsers except Chrome have access to hardware decoding and run smoothly.