So what alternatives are available (if any) that can be used with PMS?
Client apps for Apple TV
Or must I install a new server side application?
Must admit. Felt pretty silly asking my friends to wait while I “install” an ice pack
Someone posted some monstrosity of cooling fins they added to their Apple TV case to pull heat away from it.
I would just crack it open and add a fan inside. A few vents added to the case for exhaust would be a lot more pleasant looking. Also more effective at removing heat from the source instead of through the case material.
1 Like
Infuse seem to be the way for the moment. Need a little subscription, but worth every penny since this bug appears. No overheating or playback problem. Direct mode for Plex is available in the TestFlight mode and work well. I don’t say to switch forever, but it’s a good solution for waiting…
1 Like
So what is the primary issue.
The Plex ATV application is using “software” to play the video rather than hardware?
Probably a very crude way of asking, from what I can tell Apple TVs metal hardware is capable but not utilised?
Which is why other app don’t have this issue as they do utilise it?
In addition, if this issue has been ongoing for a significant amount of time, that would suggest looking at alternatives might be the only option moving forward, which would be a disappointment.
Nah, it’s using hardware accelerated decoding (all that matters in this case). Specifically, via the videotoolbox API:
(460032) 🔧 PMKMPVClient.m:519 | [cplayer] v: List of enabled features: asm audiounit avfoundation bsd-fstatfs build-date cplugins debug-build ffmpeg gl glob glob-posix iconv ios-gl lcms2 lgpl libass libdl libm libmpv-shared optimize osx-thread-name plain-gl posix posix-or-mingw pthreads stdatomic tvos vector videotoolbox-hwaccel zlib
(459977) 🔧 PMKMPVClient.m:519 | [libmpv_render] v: Loading hwdec driver 'videotoolbox'
(459927) 🔧 PMKMPVClient.m:519 | [vd] v: Looking at hwdec h264-videotoolbox...
(459927) 🔧 PMKMPVClient.m:519 | [vd] v: Trying hardware decoding via h264-videotoolbox.
(459976) 🔧 PMKMPVClient.m:519 | [vd] v: Pixel formats supported by decoder: videotoolbox_vld yuv420p
(459976) 🔧 PMKMPVClient.m:519 | [vd] v: Requesting pixfmt 'videotoolbox_vld' from decoder.
(459673) 🔧 PMKMPVClient.m:519 | [ffmpeg/video] debug: h264: Reinit context to 720x416, pix_fmt: videotoolbox_vld
(459790) 🔧 PMKMPVClient.m:519 | [vd] v: Pixel formats supported by decoder: videotoolbox_vld yuv420p
(459790) 🔧 PMKMPVClient.m:519 | [vd] v: Requesting pixfmt 'videotoolbox_vld' from decoder.
(459964) 🔧 PMKMPVClient.m:519 | [ffmpeg/video] debug: h264: Reinit context to 720x416, pix_fmt: videotoolbox_vld
(459964) ➖ PMKMPVClient.m:511 | [vd] info: Using hardware decoding (videotoolbox).
(459964) 🔧 PMKMPVClient.m:519 | [vd] v: Decoder format: 720x404 [404:405] videotoolbox[nv12] auto/auto/auto/auto/auto CL=mpeg2/4/h264
(459964) 🔧 PMKMPVClient.m:519 | [vf] v: [in] 720x404 [359:360] videotoolbox[nv12] bt.601/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
(459964) 🔧 PMKMPVClient.m:519 | [vf] v: [userdeint] 720x404 [359:360] videotoolbox[nv12] bt.601/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
(459964) 🔧 PMKMPVClient.m:519 | [vf] v: [autorotate] 720x404 [359:360] videotoolbox[nv12] bt.601/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
(459964) 🔧 PMKMPVClient.m:519 | [vf] v: [convert] 720x404 [359:360] videotoolbox[nv12] bt.601/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
(459964) 🔧 PMKMPVClient.m:519 | [vf] v: [out] 720x404 [359:360] videotoolbox[nv12] bt.601/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
(459927) ➖ PMKMPVClient.m:511 | [cplayer] info: VO: [libmpv] 720x404 => 720x405 videotoolbox[nv12]
(459927) 🔧 PMKMPVClient.m:519 | [vo/libmpv] v: reconfig to 720x404 [359:360] videotoolbox[nv12] bt.601/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
Maybe there’s some confusion between video decoding and the use of OpenGL vs. Metal for rendering?
1 Like
I’ve been using Infuse for years. It causes overheating on our Rokus (as I have mentioned). Only with 4K HDR content.
I don’t have 4K ATVs, only some really old HD ATV’s (which don’t have any issues with Plex).
1 Like
@JohnAlex You’ve been using Infuse on Rokus ?
On iPhones and iPads.
I’m firing feed to the Rokus
Edit - iPhone 13 is a good hand warmer when doing it 
Please note that these are Telstra provided Rokus with a tuner built in. Custom FW for AU use.
But mentioning some niche unsupported usage case doesn’t seem that relevant to how Infuse performs.
(To be clear, Infuse officially supports casting to other Apple devices and ChromeCast. It doesn’t support DLNA or casting to anything beyond the devices above.)
Using the Infuse app on my iPhone 13 and playing directly causes no heating issues on the phone. Casting from the phone to ATV 4K with Infuse causes absolutely no heating issues to the ATV 4K or to the IPhone 13.
1 Like
That was not point of the comment.
It seems there is a certain sensitivity in this thread so I’m out.
Good luck to those having issues.
I’m sure Trust_the_Process, is not trying to press your buttons or alike. I have known this dude for quite some time, he is just pointing out which I agree, that it is a fringe use case and should be considered with only small possible merit at this stage. So please don’t leave on our account
What you posted seems to be an h264 file, while many of the problematic 4K HDR files are HEVC h265.
But whether or not the Plex player is using some hardware optimization for some parts of the player stack for some types of decoding, it’s fairly obvious that for this common stuttering issue, there’s a lot more CPU use (and heat generated) playing the identical file with the Plex player than with the player in apps like Infuse.
I suppose there’s some value in being precise in our language about what we mean when we say the Plex player isn’t using hardware acceleration, but I think for the context of this discussion, that value is fairly low.
When folks (rightly) point out the difference in players and wonder why. The reason is that the Plex player isn’t using (the same amount of) hardware acceleration available on the AppleTV device that other players are.
A specific statement was made up-thread that Plex’s tvOS client wasn’t using hardware acceleration for decoding.
There is value in using precise language. But no amount of precision would make the above statement regarding the use of hardware-accelerated decoding correct. It seems to have caused confusion for at least two people (me being one, because I thought it did), so I tested and shared my results.
Please try to accept my original post in the spirit for which it was intended. That is, to ensure that correct information regarding the Plex client’s use of HW-accelerated decoding was represented in the thread. It doesn’t detract from the original point in any way; in fact, it may help in understanding where the problem may (or may not) be in the player stack.
And yes, that log did show an excerpt from playback of an H.264-encoded file. Here’s a 10-bit, H.265, HDR10 playback showing hardware-accelerated decoding for completeness’ sake.
(950320) 🔧 PMKMPVClient.m:519 | [cplayer] v: List of enabled features: asm audiounit avfoundation bsd-fstatfs build-date cplugins debug-build ffmpeg gl glob glob-posix iconv ios-gl lcms2 lgpl libass libdl libm libmpv-shared optimize osx-thread-name plain-gl posix posix-or-mingw pthreads stdatomic tvos vector videotoolbox-hwaccel zlib
(950193) 🔧 PMKMPVClient.m:519 | [libmpv_render] v: Loading hwdec driver 'videotoolbox'
(950310) 🔧 PMKMPVClient.m:519 | [vd] v: Looking at hwdec hevc-videotoolbox...
(950310) 🔧 PMKMPVClient.m:519 | [vd] v: Trying hardware decoding via hevc-videotoolbox.
(950289) 🔧 PMKMPVClient.m:519 | [vd] v: Pixel formats supported by decoder: videotoolbox_vld yuv420p10le
(950289) 🔧 PMKMPVClient.m:519 | [vd] v: Requesting pixfmt 'videotoolbox_vld' from decoder.
(950193) ➖ PMKMPVClient.m:511 | [vd] info: Using hardware decoding (videotoolbox).
(950193) 🔧 PMKMPVClient.m:519 | [vd] v: Decoder format: 3840x2160 [0:1] videotoolbox[nv12] bt.2020-ncl/bt.2020/pq/limited/auto CL=mpeg2/4/h264
(950193) 🔧 PMKMPVClient.m:519 | [vf] v: [in] 3840x2160 videotoolbox[nv12] bt.2020-ncl/bt.2020/pq/limited/display SP=49.261086 CL=mpeg2/4/h264
(950193) 🔧 PMKMPVClient.m:519 | [vf] v: [userdeint] 3840x2160 videotoolbox[nv12] bt.2020-ncl/bt.2020/pq/limited/display SP=49.261086 CL=mpeg2/4/h264
(950193) 🔧 PMKMPVClient.m:519 | [vf] v: [autorotate] 3840x2160 videotoolbox[nv12] bt.2020-ncl/bt.2020/pq/limited/display SP=49.261086 CL=mpeg2/4/h264
(950193) 🔧 PMKMPVClient.m:519 | [vf] v: [convert] 3840x2160 videotoolbox[nv12] bt.2020-ncl/bt.2020/pq/limited/display SP=49.261086 CL=mpeg2/4/h264
(950193) 🔧 PMKMPVClient.m:519 | [vf] v: [out] 3840x2160 videotoolbox[nv12] bt.2020-ncl/bt.2020/pq/limited/display SP=49.261086 CL=mpeg2/4/h264
(950310) ➖ PMKMPVClient.m:511 | [cplayer] info: VO: [libmpv] 3840x2160 videotoolbox[nv12]
(950310) 🔧 PMKMPVClient.m:519 | [vo/libmpv] v: reconfig to 3840x2160 videotoolbox[nv12] bt.2020-ncl/bt.2020/pq/limited/display SP=49.261086 CL=mpeg2/4/h264
But a contextual reading does make it both semantically and germanely correct:
“Only in the Plex app though, which doesn’t use hardware decoding and rendering available on-device. Infuse, etc that do use the hardware decoding and rendering available on-device run fine with or without active cooling.”
Please accept my response to your post in the spirit it was meant, that I don’t think the distinction between the above sentence with or without the italicized words changes what is meaningfully being said when responding to questions by users like “Why does Infuse work?” or “AppleTV must need a fan.”
That comment wasn’t to a Plex dev. The Plex devs know what’s happening under the hood. They found the thermal throttling. They know it’s caused by excessive CPU use and insufficient use of hardware acceleration. I don’t think the clarification of the italicized words have any effect on their diagnosis or solution.
But yes, 
agree that the clarification of the italicized words are necessarily to be semantically precise and there is value in that.
I just don’t think there’s enough value in that to a response like “Why does Infuse not have a problem?” or “AppleTV must need a fan,” to bother with me typing another word on the subject. 
It’s not only this thread which is relevant here. Sooner or later, someone is going to come to these forums (or fora, if you prefer) and search for something like “Apple TV 4K hardware decoder” and your post is going to be fairly high in the results list.
https://forums.plex.tv/search?q=Apple%20TV%204K%20hardware%20decode
Having read that, they may get the idea that hardware decoding is unavailable on the Apple TV 4K. (Heck, they still might.) So, it’s important to have the correct information available. Plus, having it does nothing to diminish your original argument.
We can go back and forth regarding the statements’ value in one context or another. However, the initial assertion was made in the context of this thread. If it was valuable enough to make that assertion then, it’s of value to have correct information now.
Awesome find OP! Reading over the thread, I’ll have to agree with what @johnblaze00 was saying though. If the Plex app is causing the Apple TV 4K to thermal throttle, aren’t we really avoiding the main issue here if the Plex devs aren’t comparing the performance of Infuse (or other apps) vs the Plex app? Here’s what James (Infuse dev) said about their player back in June 22:
“Many apps use mpv or VLCkit as the foundation for their apps, as they are generally pretty good and save a lot of development time.
However, we began creating our own player in 2010, in the good ol’ days of the 2nd gen Apple TV. We did this to allow us to improve the performance when running on the Apple TV. Since then, we’ve continued to develop our player and fine-tune things for the devices Infuse currently runs on.
Infuse’s player application sits on top of other components, like FFmpeg, which handle a lot of the grunt work for processing video. As of today, FFmpeg is included in most every piece of software that processes audio/video. However, there can be big differences in how the implementations are put together, so that is why Infuse, mpv, and VLC all perform a little bit differently.”
The only outlier on my end with Apple TV is a ATV4K 32gb I have from 2017. It plays everything (outside of TrueHD) with no problems and no frame drops. But my 128gb ATV4K cannot do the same. I truly don’t understand it! Hopefully devs are getting closer to fixing the issues.
1 Like
They are doing just that now that the issue is known! This is why I’m optimistic that a true fix is coming. If you go over these stuttering threads going back several years, you’ll see that a TON of effort was made trying to resolve this. But it was all work that was cutting off heads of the hydra, the specific issues with specific causes they could reproduce, not the heart of the issue.
I’m sure Plex is now looking at the issue named something like “Maximize use of hardware rendering on AppleTV” in a very different light now. Before such an issue would have been fairly low priority, a nice to have feature. Now it could be the silver bullet to resolve almost all the Stuttering issues they’ve probably spent WAY more budget playing whack-a-mole with.
It’s all about budgeting dev time, and until now it CPU/hardware optimization and stuttering hadn’t been connected. So that changes the dev-budgeting decisions.
I have no idea if it’s the same issue. But even if it’s the same 2017 AppleTV with the same thermal set and setting, having a much bigger (or even just a different) nand flash chip inside could certainly generate more heat. Which of course would manifest stuttering differently depending on the specific file and thermal state, etc.
1 Like
Also running into this issue. Audio plays fine while the frame rate is a near slide-slow level.
I posted in this thread as well - it seems to me that these two issues are the same. Maybe it would be best if all discussion was limited to one thread.
It’s related to this
1 Like
I have a 2022 ATV.
To test this I threw my ATV in the freezer for an hour, took it out immediately, and tried playing a file that gives me issues.
It started stuttering immediately.
I don’t think heat issues have anything to do with this issue. Or at least one of them.
