I use it for our 65 inch Sammie
Picture quality looks just as good as any other media player I have (Kodi, VLC etc) ?
It is designed for a HTPC. What HTPC playback options do you mean ?
I can’t disagree as we all see things differently, just sharing as well from my point of view.
we currently use for physical media ub9000, and for digital media htpc playback we use mpc-hc via madvr (front end gui is Composite). if i take 2-3 common scenes from some decent reference movies (i.e. Mad Max, The Martian, Pacific Rim, 1917, Skyfall) , and compare plex htpc to madvr, it is still night and day for the video processing (dropped frames, chroma processing, overall sharpness and gradation) of what i can see. especially with HDR content, but SDR is still better as well.
Doesn’t mean that there re not a lot of folks happy with current status, i am just looking for more comparative video quality, as i would have no reason to want take a step backwards in the home theater.
I found that at anything above normal quality I would get stuttering and audio sync problems.
On normal with hardware decoding on and refresh rate change turned off get a smooth, clear image without any audio delay and responsive interface.
I’m still getting stutter during playing on a RTX3090 & Ryzen 5900 machine using 1.6.1
This is a long post with a lot of detail so read carefully. Many have commented on the stutter and from what I’ve seen there are two types:
- A stutter which occurs occasionally for a short period of time with long random intervals in between
- A stutter that occurs continually for a playback but a pause/resume tends to resolve.
Both of these are particularly noticeable when refresh-rate matching is enabled. To explain what is going on, I first have to explain some architecture. This is very similar to PMP so anyone who has studied that can very well guess everything I’m going to describe here.
The Current Render Process:
MPV is currently using the libmpv renderer which renders into an OpenGL frame buffer object. This allows it to be rendered within a scene with other elements. This is how controls are easily rendered on top of the video or the video is rendered on top of the controls for instance (both modes are currently used in different circumstances). This process goes through elements starting with the back-most element and rendering them till it has finished all elements and that constitutes a frame which is displayed on the screen. Since Qt enables us to easily integrate Chromium (the basis of the Chrome browser) into this view, we used its rendering architecture for the entire render process.
The Cause of The Stutter:
Qt has two modes of rendering where one is threaded and the others are not. If you read through Qt Quick Scene Graph | Qt Quick 5.15.6 you can see that MacOS lost the ability to use the threaded render pipeline when apps were built against the 10.14 or higher SDK (which we need for other things). Windows cannot use the threaded render pipeline when ANGLE is in use because the library isn’t thread-safe. I believe that in the old PMP on Windows we were able to use the threaded render pipeline but I’m not 100% certain of that.
So we have a render pipeline that uses the main thread for the process effectively blocking it for that time. This means that events which run on the main thread (which is going to be just about everything) have to wait for the render pipeline to finish before they get processed. These queued events get processed between frames which can change the timings of the start of the next frame render. This results in jitter in the timings of when MPV’s render function is called. In certain circumstances this can cause the timing of this function call to be on the edge of a frame time and thus randomly fall on one side or the other of a frame’s time (type (2) above). Additionally one these event that gets stuffed into this queue waiting for the main thread is the request by MPV to render the next frame. If this event isn’t processed in time for the next render run start, the video frame just won’t get rendered in the next frame (type (1) above).
In the threaded render pipeline, the main thread is only blocked for a short period of time and so events that run there don’t build up as much. This means that the aforementioned event for MPV requesting a render is much more reliably processed before the render pipeline starts the next frame.
What’s To Be Done?
We’ve attempted to introduce our own threading into the pipeline using two frame buffers which are rendered in a separate thread for just MPV. This involved creating a new GL context which is assigned to the thread and allowed to share frame buffers with the main context. It worked well on MacOS. Windows was … a different story. There it produced a stochastic flash pattern between the correct frame and black which it proceeded to do for a few seconds before it crashed in ANGLE. Apparently even this very limited threading was beyond what ANGLE could handle.
Recently Qt 6.2 was released which is the first of the Qt 6 line that could potentially be used because it’s the first that contains Chromium. Though it’s worth noting that switching to it is not just a simple drop-in replacement so don’t expect that soon. It does away with ANGLE completely on Windows and ceases using OpenGL on Mac. Instead it uses D3D and Metal respectively. Since libmpv still requires rendering into a GL context, we would have to layer our own ANGLE on top of D3D. In this case ANGLE would only ever be on a single thread so hopefully it will work fine. On MacOS we can make a texture that’s compatible with both Metal and OpenGL so we can have libmpv render to it using OpenGL and put that in a Metal command buffer to render.
Linux?
I’ve not mentioned Linux above because it’s the platform where things don’t change. It can still use the threaded render pipeline and in Qt 6.2 it still uses OpenGL. So there’s just not much to discuss there and that’s a good thing.
Can We Eliminate Qt’s Renderer For Video?
Another avenue which we are examining is the possibility of pulling MPV out of Qt’s render pipeline. I mentioned earlier the contention of the main thread and even with the threaded renderer that problem won’t be fully eliminated. The fact is that way too much of Qt’s design is reliant on running on the main thread, likely due to the fact that Qt does make threading harder than it should be. We previously mentioned this in the context of saving settings taking so long on the main thread and I recently discovered another example of this which will be fixed in the next version. So we are investigating the possibility of separating Qt and MPV’s render process entirely from each other. Considering that every example of stutter I’ve seen has been entirely the fault of something in Qt, this has potential to completely and permanently eliminating the problem. While there is hope that this will work, this is a large architectural shift which could bring some nasty surprises so keep your fingers crossed.
11 Likes
Hello, could you please provide a timescale for the Linux release of the HTPC app ?
Hey, finally ironing out some issues on my end and plex htpc is running great! Only problem is I can’t get it to save my settings when I exit, including my sign in! Every time I exit and restart I have to sign back in. I set it to auto login amongst other things but it doesn’t save any of it. Am I missing something? Thanks!
It’s being actively worked on. I tested out an internal build yesterday of Desktop (not HTPC but they are similarly built) and I could browse and play content. It still has some issues but it’s making progress.
Did you make the plex.ini file read-only? Some people did this to try to combat some stutter in the earlier days but that action is no longer necessary.
2 Likes
Thank you so much for the detailed reply. We greatly appreciate the update. I had updated to 1.6.1 yesterday and still experienced the stutter (Scenario #1). Interestingly enough, it seemed a little better with the refresh rate matching turned on. I went back to PMP for the moment (and the Samsung Smart TV app ain’t bad, but it also seems to stutter a bit) and will patiently await an update.
It’s probably already been asked, and I apologize as I’m not on here often… but if you’re looking for beta testers, I politely raise my hand. Would be happy to test-drive and provide logs/feedback
1 Like
Thanks @gbooker02 for the detailed explanation.
I run HTPC 1.6.1 on Windows and am experiencing the occasional but quite noticeable stutter during playback (scenario 1).
I am pleased to read you have found the root cause of the stutter and you are attempting to find a solution. Keep up the good work!
I am looking forward the next HTPC release and hope the stutter issues will be solved.
Isn’t everyone running a forum preview build a beta tester? 
I found one cause of scenario 1 but it may not be the only one. There’s also scenario 2 which is a different issue entirely.
On another note: the tests of pulling MPV out of Qt’s render pipeline are going well. Playback is already working on MacOS which I did first because it has the more sensible view hierarchy. There’s still a lot of window handling code that needs to be moved/redone since Qt is no longer in charge of the application’s main window. Then comes the fun of Windows but some parts have already been tested there and work so it shouldn’t be an issue. Additionally this approach will likely make HDR support much easier.
2 Likes
So what type of displays and sizes are you testing with? OLED, Projectors, UST Projectors, Standard LCD etc.? …65" 77" 85" 120" etc.?
When you do the code-reworking will you be dropping the new engine into the latest UI ‘Modern interface’ or the current, older ‘Smart TV interface’?
Really hope it’s the former!
I don’t see how this question is remotely related to the section of my post you quoted. As such I don’t know what you are actually asking.
The new UI is coming to HTPC but I cannot answer as to the timing.
As per my recent work, I got playback working in Windows. There are some fun quirks ATM on all platforms (you know you want the mouse to never be hidden and live in the center of the display, right?). A few things appear better like the UI is more responsive during playback. I cannot answer to the stutter yet because refresh rate matching needs to be fixed first and I’ve simply not played enough content on it to say anything definitive.
1 Like
ok, the question is what are you testing the revisions of the application “Plex HTPC” on from a display preservative. you noted “Playback is already working on MacOS”, ok but on what kind of display is it working already on? Or do other Plex staff in your group and not yourself do the testing of the application when making changes?
When we as users are looking for “Plex HTPC” to delivery great picture quality, the question what type of Display and Size you test the application with is very important , as it can lead to gap in what users are experiencing, for example in the poll there are 14% of user that use it on a laptop, which is ok, but that is not the user base for “Plex HTPC”.
Ok, so I was correct. Your question is completely unrelated to the the section of my post you quoted. The answer is: IT DOESN’T MATTER! This is the kind of thing where the type of display is irrelevant because the possibilities are that the app would crash, it wouldn’t display anything, it’d mangle the video by clipping or scaling incorrectly, or it would display the video properly. It did the last.
The feature has now been enabled. If you are running 1.6.1, you can now use the modern layout. You may need to restart the app for it to notice that we enabled the feature.
2 Likes
ok, so in general does the plex staff during the development of product (plex htpc) test on display’s?
Love the new layout - thank you so much.
Hi @dseto … I think you are getting a little too hung up on the display side of things.
In regards to your original question…
It definitely doesn’t matter what size of display is being used when testing the Plex products, and nor does it make any difference if a display is OLED, QLED or LED.
The only 2 things I can think of that will matter, would be HDR compatibility (definitely including Dolby Vision) and support for Frame Rate Switching.
Beyond those 2 things, the type or size of display is irrelevant.
I can understand and respect the point of view, but i feel the simplicity of the questions it just pretty simple to confirm either way. So we will just have to kindly agree to disagree.
If plex only works on the software architecture of the product development and does not test on displays (which is ok, if that is their business model) then it would explain the difference in what customers are seeing in real world usage for picture quality of the video rendering.
