Using up to date latest image with Kodi Matrix on a RPi 4B+. It is in an aluminum case with heat dissipating pads. The output device is an Epson 3800 projector with up to date firmware. The entire run from the Pi micro-HDMI port to the projector is 8K-class high quality HDMI cable. I noticed these strange bugs in running through the OSMC provided 4K/60 test video.
I have to enable expert mode to set the GUI resolution limit to “1080”. Otherwise, when enabling any framerate > 30Hz in the GUI, the signal is lost. I’m glad this setting fixes the problem, but imagine my surprise when the projector reports a 3840x2160*60Hz mode in the GUI afterwards and everything seems to be working fine in the GUI (and with 60Hz framerate)! What is going on here?
There is a 4096x2160 mode available which in fact works, but does not allow selecting > 30Hz framerate in the GUI, which I don’t quite understand. Even stranger is that there are two 3840x2160 modes; the second one works as expected, but selecting the first one results in a loss of signal to the projector. Is there debug information around the modes presented to the user somewhere I can dig into?
When playing the 4K/60 test video in the default player, occasionally it plays through smoothly and as expected. On most test playthroughs, the framerate drops to some extent which is not that severe but noticeable during panning. I might blame this one on cabling; however - on the occasional test playthrough, the video signal (as reported by the projector) switches between 59.94Hz and 60.00 Hz which creates a disruptive mode switch. I don’t know if it’s related to the framerate drop, but in any case what could possibly cause a mode switch in the middle of playing back a video?
Thanks in advance for any pointers. I am very close to having a satisfying 4K/60 RPi4 setup.
I don’t see how that would be possible. If you set it to 1080 it switches to that and asks you to confirm. If you don’t confirm it will switch to the previous resolution but then the UI also changes the setting to reflect the mode it is running in. I’ve never heard or seen where OSMC was outputting differently than what the setting was showing. That is unless you looked at the resolution not when you were in the UI but during playback when refresh rate switching was enabled in which case it is suppose to change video modes to more closely match the playing video.
During startup or when it sees a display connected there is communication where your connected display reports which video modes it supports and that is what is presented to you minus any that your device does not support. As for the 4k 60hz I believe that is only supported on the RPi 4 if you are connected to the HDMI that is closest to the power plug, nothing is connected to the second display port, and you manually enable this mode in config.txt.
I’d guess that your not playing at 4K 60hz so the stuttering your seeing is due to the non-matching frame rate. To know for sure you would need to produce debug logs. I’m not sure about the frame rate switch in the middle of the video. If you have the refresh rate switching set to “always” you could try changing it to “on start/stop”. You could also try another HDMI cable and see if that makes a difference.
Correct, this matches my configuration. I am not certain any of this would work at all otherwise – at least the 60.00 Hz modes were not even offered until the config change was made.
Is the projector itself not a trustworthy source for mode information? Also, you can see from the debug information on-screen that it’s reporting 60FPS framerate when paused, although I don’t know if this is the player, video driver or something else reporting this.
Refresh rate switching is set to “on start/stop”. Sync video playback to mode produces “different” stuttering (when enabled it’s more sporadic; when disabled it’s more predictable within a given video).
Multiple cable attempts, same/similar results:
A 1.5M micro-HDMI to HDMI cable rated for 8K, whatever that’s worth.
A 4K-rated micro-HDMI to HDMI dongle with a 2M 4K cable.
A 20 foot (!) 8K cable run through an active extender (worst case, but really doesn’t behave any worse or even differently than the others).
It doesn’t happen on every playthrough, but “eventually” the switch to 60Hz will happen within a handful of runs if I loop the video. Then, when the video starts over the framerate is switched back to the video’s native 59.94Hz. The spurious mode switch tends to happen around the same part of the video.
It looks like the disparity on the UI resolution setting is that you were looking at it with the video still playing in the background. When you have refresh rate switching set to start/stop it sets the video mode when the video starts and it doesn’t change until playback stops. This includes when you return to the UI without stopping the video first. If you have refresh rate switching set to always then it would have switched regardless.
As Sam had stated you don’t actually want your UI set to anything other than 1080p. Refresh rate is personal preference. You can set it to match what you watch the most so there is less screen blackouts at the start of playback. If you want control over which video mode is used during playback the way to do this is with a whitelist. You can find a guide about that [here]
You mean sync playback to display? If so, do not enable that. It doesn’t work and even if it did it is not optimal.
As for the video switching while you looping the clip I would suggest that maybe there is a cache or buffer issue that comes up playing the same clip repeatedly. I remember doing a bunch of tests with jellyfish test files looking for more optimal Kodi cache settings. I ran into an issue playing the same files back to back as I would end up with non-repeatable results. This of course is just a guess and if you produced some debug logs more insight might be had.
Before I muddle things any further, what exactly does the “set GUI resolution limit” option do? I had hoped it would provide an upper bound on the GUI resolution regardless of any other factor.
If you check out the howto I linked to in my last post that should give a decent understanding of how these systems operate and how you can control them. Basically the UI resolution does two things. The first is set the output display mode when your not playing video. It is not recommended to run this in 4K as it makes things slower and can cause off behavior to happen. The other thing it does is set the lower floor for video playback sans manual whitelist. Normal operation with refresh rate switching enabled is to pick the closest video mode to the source that is at the GUI resolution or higher. With a manual whitelist you can choose which modes are available to be picked which can include allowing switching to lower resolutions as well as blocking choosing which ones to never use. It can be a bit confusing, but that guide should provide just about any answer you would be looking for on the topic.
EDIT: Sorry I typed all that up and then after hitting send noticed I answered the wrong question. The GUI resolution limit is for making the UI render in a lower resolution that what your display is outputting. This is not something that should have any significant benefit to you.
Okay, I will rework my settings according to the linked howto and report back. It seems so strange that the default display and playback settings appear to be closer to the opposite of reasonable, and that this extensive/arcane manual setup needs to be done to get to a real starting point. I wonder if any thought has been put into streamlining this setup for a new box?
Isn’t the default settings come with refresh rate switching set to always and the GUI set to 1080p 60hz? If so this is optimal for most people. With these settings you optimize playback smoothness and the UI doesn’t go low res when your playing back an old DVD (which is a downside to whitelisting the lower resolutions). When playing back 4k it will also automatically switch to 4K modes your display says it supports. Sometimes people want or need a bit more control for one reason or another and that is where one may need to tweak a bit. How these system work can be a bit confusing thus the writeup. The alternative is that we default to outputting a straight fixed display mode and let video quality suffer. It used to be that way and there were way more people asking related question back then than after the change.
Hmm, I’d have to dig a bit since I’ve been messing around with the settings but I’m pretty sure this defaulted to “On start/stop” (which in turn prompted my original confusion point 1). Also, the howto makes it seem like there would be no drawbacks to e.g. setting up a whitelist with all modes by default. I’ll get that set up and get a debug log going if 4K playback is still weird.
It might. There are differences in opinion across the dev team on which is the better default option and I wouldn’t be surprised if I got the final decision mixed up. For the vast majority of users they wouldn’t notice or care about the difference between the two options. Really the issue is allowing the video mode switch which enables 4k playback and better video quality.
That isn’t quite accurate. The fish who wrote that is a big fan of the feature so he certainly isn’t going to discourage people from taking advantage of it, but he does not recommend selecting all modes and details quite a few modes with pros and cons for people to consider. The drawback is that someone had to make decisions and they are particular to how an individual wants their device to operate. In order to properly make those decisions you need to understand quite a bit as you see from the guide. And this is why the whitelist isn’t, and will never be enabled by default. It is an advanced feature for people who want more control.
Okay, I’ve set all the recommended settings including:
video mode switch - Always, and verified that UI is rendered 1080p 60Hz regardless of playing video
sync playback to display - Off
Whitelist enabled and added all modes to it
However, the intermittent frame drops in the 4K/60Hz test video are now worse than in previous testing. I’m not exactly sure what should have made it worse.
Debug logs here: https://paste.osmc.tv/vuwuzanogi
I played one 4:3 video as a quick sanity check before setting the 4K/60Hz test video on a loop.
One thing I notice is that Kodi is using more than 1 full core (combination user/sys cpu%) with the video paused. Is that expected? That seems … suboptimal. I tried to quickly perf top but looks like the package linux-perf-5.15 is not included in the distribution which would be needed for the 5.15 kernel.
The frame drops and black frames wouldn’t be related to video mode switching other than if you disallow high bandwidth signals to be sent you don’t generally have the problems that can happen with them. The video switching is working so what’s left is the non-perfect playback. I grabbed the test clip your using and it looks to me like the RPi 4 isn’t able to cope with that particular torture test (my source is good as my Vero plays it perfectly). I could not get it to play without some stuttering happening at some point in the clip. Honestly though, I’m suppressed it did as well as it did. I didn’t get any black though and I think that is most frequently caused by cables. Marginal PSU (RPi 4 seems to be a bit fussy about its power source) could maybe cause this type of thing under load I’d imagine (your logs are not flagging a voltage drop though). Also playing from a SD instead of the Network may cause additional load. I think the HEVC 10-bit 59.94fps (Korean ATSC 3.0 satellite TV capture sample) may be the better test as the RPi 4 seems to have no issue handling that one. That is unless your so keen to get the first clip perfect you have a go at overclocking but that is outside the scope of this forum and not something I’m going to be playing with.
Once I realized that debug logging was limiting framerate to 40fps, I tried your test and one other HEVC 4K/60 test video from that page. Your test video plays perfectly, and the third test video stutters from time to time but slightly less than my first test video.
I’m using a Mac 87W USB-C power supply (it’s what I had at hand).
Playing from SD compared to network has no discernible effect.
Since the board is in a high quality metal case I did try overclocking both CPU and GPU (and verified the CPU was clocked higher during playback). Unfortunately the same level of stuttering was still present. While it’s stuttering, the temp is under 60C, core utilization is balanced and none of the cores is over 25% utilization.
This is quite puzzling at this point. With the one working test video in hand should I just conclude the stuttering (on two of three test videos) and framerate switches (observed only on the first test video) is a player problem with certain HEVC files, file an upstream bug and move on?
Edit: Come to think of it, it might not be a player problem because you said it works on your Vero. Does the larger test file “HDR 10-bit HEVC 59.94fps (in MP4, Camp by Sony)” also work without subtle stuttering for you?
It wasn’t. I’m guessing you were looking at the speed at which the UI was being refreshed. But yes, having debug and the overlay can make things work not as well as if they are not enabled.
On the first playthrough it did one slight stutter a second or two in and otherwise I saw no fault. The second playthrough I saw no issues.
This isn’t optimal. Although the Apple chargers are usually of a much higher quality than your standard fair they still are chargers and not proper power supplies. Chargers don’t need to provide a stable fixed voltage as this increases costs and provides no benefit when your only charging batteries. As a result it is common when someone uses a charger as a PSU to have the device seem to work fine but when the device starts to draw a higher load the voltage drops and/or becomes less stable. For some it may make no difference. When your trying to push the edges to something a SBC is capable of doing like pushing 4K 60hz it may.
Unless you have any real content that you want to watch in this format the entire exercise is a bit academic. I’m not sure what I would classify as a bug as all I’m seeing is really a Pi struggling with a really large and complex file that I don’t think anyone ever made any claim that it could pull off. The software is in a constant state of improvement so it may do better in the future with updates. If you really wanted to you could try running LibreElec and see if that OS is able to do better.
I played it on both. The Vero didn’t hiccup. The RPi 4 I was was playing on is a 2GB in a FLIRC case being powered by a cheap external POE power adapter (just standard no name $12 jobs you find on Amazon) and plugged into a LG 4K UHD TV via a mini HDMI to HDMI cable (the adapters seem to be less reliable) that if memory serves is an Amazon Basics brand, but even if it isn’t I do remember I paid $6 for the cable (ie nothing special with magic gold plating). I run the UI at 1080p 59.94 (less video switching when watching live TV), no whitelist, refresh rate switching set to on start/stop. The test was being run on current stable and that box has never seen a test build.
I actually have four of these boxes that are identical other than one uses an official RPi PSU and one runs up to date test builds.
