[Zuikkis]

Most of Android developers perhaps have Nvidia Shield, which doesn't have this bug. Correct resolution is selected, with or without whitelist.

Though even with Shield, resolution is changed twice. But it seems to always select the same resolution so it doesn't matter. Sometimes the second resolution change results in few seconds of black screen, though.

[Kayn]

Most of Android developers perhaps have Nvidia Shield, which doesn't have this bug. Correct resolution is selected, with or without whitelist.

Though even with Shield, resolution is changed twice. But it seems to always select the same resolution so it doesn't matter. Sometimes the second resolution change results in few seconds of black screen, though.

Ah ok, so you're telling me that's shared knowledge that the Nvidia Shield doesn't have this issue... and therefore this bug it's necessarily related to the Fire OS.

[Zuikkis]

These 1088 and 2176 resolutions shown in logs are interesting. Maybe something somewhere decides that y-resolution should be divisable by 32 or 64, and rounds 1080 and 2160 up? Then the CRenderer notices that display resolution is incorrect   (1080 vs 1088, 2160 vs 2176) and tries to find a new screen mode.

[Kayn]

These 1088 and 2176 resolutions shown in logs are interesting. Maybe something somewhere decides that y-resolution should be divisable by 32 or 64, and rounds 1080 and 2160 up? Then the CRenderer notices that display resolution is incorrect   (1080 vs 1088, 2160 vs 2176) and tries to find a new screen mode.

Yes, they're interesting especially because they have nothing to do with the original resolution. For example the video I've used has a resolution of 3840x2076; I don't understand how and why it could became a 3840x2176...
Also the 1088p that's shown in the 720p case: the video is a full 1280x720p and out of the blue it becomes a 1980x1088...

[Zuikkis]

Most of Android developers perhaps have Nvidia Shield, which doesn't have this bug. Correct resolution is selected, with or without whitelist.

Though even with Shield, resolution is changed twice. But it seems to always select the same resolution so it doesn't matter. Sometimes the second resolution change results in few seconds of black screen, though.

I'm quoting myself as I just had time to test this further.

Turns out I was wrong. The "few seconds of black screen" is indeed caused by screen resolution change.

My ancient Sony videocam records videos with "fullhd" resolution, 1440x1080@50i:

- With whitelist enabled, Kodi first picks 3840x2160 resolution. After a few seconds it is changed to 1920x1080. Here the question is, why did it pick 4K in the first place?
- With whitelist disabled, Kodi picks 1920x1080 right away. After a few seconds it does another check but it results in same 1920x1080 so nothing is changed.

So with whitelist disabled it actually works very well, I'll keep it that way. However I'm sure these same videos worked without issue with whitelist enabled in some earlier Kodi version! But can't pinpoint exactly when this started. Now I'm using a nightly from 1.1.2024.

Also, this statement from @fritsch is incorrect:

If you disable the whitelist, kodi's behaviour is: Check all refreshrate of the current resolution we have, but also allow switching upwards. This default is coming from a time where most devices were too weak to run a 4K Gui at 60 hz, so people used it at 1080p60, but also wanted to switch up to 4k@24p, 4k@30 and so on for their native video output.

I am running GUI at 4K, yet Kodi selects 1080 mode for 1080 video, if whitelist is DISABLED.

Edit: come to think of it, I ran these tests back to back and I have Kodi setting to only adjust refresh rate at  start of playback (not end of playback). So it's possible test#1 changed to GUI resolution to 1080p? I'll have to test again..

Edit2: Here's a video for your viewing pleasure. About 11MB in size.

https://zuik.org/2010-03-25_00301.mkv

[fritsch]

The code was written 6 years ago, please don't generalize Android behaviour from a mixed quality firmware. If you see behaviour that does not match the code, please post your log - especially for the whitelist / no whitelist the code is very verbose and logs out everything it finds.

Without whitelist the "current resolution" is chosen and depending on that all available modes that are higher or equal are added to a list. This list is then used for finding the proper resolution / fps.

[jogal]

I am running GUI at 4K, yet Kodi selects 1080 mode for 1080 video, if whitelist is DISABLED.

This is the expected behavior (no bugs). Whitelist disabled is similar that whitelist with ALL modes selected.

If you want video upscaled by TV you should NOT USE the whitelist.

If you want video upsacaled by Kodi (Shield AI upscaling, Windows DXVA upscaling with or without Super Resolution) you should use whitelist with only 4K modes selected.

Others combinations probably not has much sense in any scenario (as whitelist with all modes selected).

https://forum.kodi.tv/showthread.php?tid...pid3183518

[Zuikkis]

@jogal and @fritsch , I understand what you are saying. And as I said, it seems to work as I want now that I have disabled whitelist.

But still there is the mystery: why does Kodi change resolution twice? First at the start of the video, then again 2-3 seconds later. It does not matter if both cases choose the same resolution, but still it can be seen in logs. This behaviour was not there a year ago. And in some cases result is different for each case, as already shown in previous logs.

Also you just contradicted yourself in explaining how whitelist works.

Fritsch:
"Without whitelist the "current resolution" is chosen and depending on that all available modes that are higher or equal are added to a list."

Jogal:
"Whitelist disabled is similar that whitelist with ALL modes selected."

My whitelist had all 1080 and 4K modes, but lower resolutions were disabled.

As Kodi Omega is nearing stable, these kind of bugs should be ironed out. If it's released like this, you will get a lot more complaints.. it was not like this in Nexus.

[Zuikkis]

Oh btw, a bugged video can even be paused after 1 seconds of playback. Then unpause, and at 2-3 seconds mark it changes resolution...

It is like the initial header / metadata resolution does not match the actual stream. FFmpeg bug / regression?

[jogal]

Depending on media container (mpeg ts) or use case (live TV) is not possible known refresh rate before start playback and even in cases in which is possible known is not suitable switch resolution at first. e.g. change channel up/down on live TV cause black screen (due mode change) if channel has different refresh rate.

Interlaced content also have their particularities (https://github.com/xbmc/xbmc/blob/0a5260...#L114-L118). There are many particular cases to take into account and everything cannot be generalized. Saying that "it's going bad" without saying what type of stream is playing and without debug logs is like saying nothing. It's all much more complex than it appears from the outside...

Even if I wanted to (which is not the case), I wouldn't have time to analyze all the cases... I will only start to worry when something affects me directly or 4K Dolby Vision is reproduced at 640 x 480 

[Zuikkis]

Depending on media container (mpeg ts) or use case (live TV) is not possible known refresh rate before start playback and even in cases in which is possible known is not suitable switch resolution at first. e.g. change channel up/down on live TV cause black screen (due mode change) if channel has different refresh rate.

Interlaced content also have their particularities. There are many particular cases to take into account and everything cannot be generalized. Saying that "it's going bad" without saying what type of stream is playing and without debug logs is like saying nothing. It's all much more complex than it appears from the outside...

Even if I wanted to (which is not the case), I wouldn't have time to analyze all the cases... I will only start to worry when something affects me directly or 4K Dolby Vision is reproduced at 640 x 480 

Then maybe it's the initial resolution change that is incorrect.

My  use case from yesterday, we were watching our home videos  (of which I did provide an example a few posts earlier). It went like this, with whitelist enabled:

  - At start of each video, I get black screen as Kodi changes the resolution to 4K@25fps.
  - Then 2-3 seconds later, another  black screen as  it changed to 1080@50fps.
  - At end of video, return back to GUI. We select another video.
  - AGAIN Kodi changes to 4K@25fps, another black screen
  - Then 2-3 seconds later, another  black screen as  it changed to 1080@50fps.

So that's two screenmode changes per each video. Not very enjoyable. This did NOT happen with Nexus.

With whitelist disabled:

  - At start of the first video, Kodi plays a few seconds with the current GUI screen mode (so no black screen at start)
  - Then 2-3 seconds later, black screen as refresh rate matches.
  - At end of video, return back to GUI. We select another video.
  - Kodi does not change refresh rate again, since it already matches!

So, now we can watch dozens of videos without annyoing breaks. Oh what joy!

However, it has to be said that @fritsch 's description of whitelist is correct, yours was wrong. If GUI is running at 4K, it never chooses lower resolution, only matches refresh rate. If GUI is running at 1080p, videos can run at either 1080p or 4K. But even running at 4K-only is quite OK for me as Shield Pro has good upscaling.

But, there were already a lot of logs and example videos by @Kayn and @boboc earlier in this thread, even a case where 4K video is played at 1080... You haven't yet addressed any of these issues either.

[jogal]

  - At end of video, return back to GUI. We select another video.
  - Kodi does not change refresh rate again, since it already matches!

This is related to setting "Adjust display refresh rate" at Start/Stop or Start only (not related to Nexus vs Omega)

[jogal]

However, it has to be said that @fritsch 's description of whitelist is correct, yours was wrong.

 

Also, this statement from @fritsch is incorrect:

[fritsch]

I wrote the code in resolution.cpp 6 years ago. It works like this: if whitelist is empty, remember current resolution. This on Linux and others is the refresh rate and resolution we currently run. Then we check all modes we have and see if they are bigger or equal and add them to our before empty internal whitelist.

Then we Probe to finde the best matching. As you see it all depends on the resolution Kodi thinks is current.

Line 109 of Resolution.cpp

And why it is that way I told already. Old Intel HDMI 1.4 which could only do 4k30 or 4k24 back at the time, no one wanted a GUI with just 30 fps but also not miss native 4k video.

That's why I implemented the default like this. Switching down will only work by adding custom lower resolutions to the white list. Again: all is relative to the resolution Kodi thinks is current.

[fritsch]

Here: https://github.com/xbmc/xbmc/blob/master...n.cpp#L100

This path constructs and internal whitelist with the constraints I stated above. What could go wrong on android, caus of double switching: current resolution might be wrongly detected in the middle.