+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+---- Forum: VideoPlayer Development (https://forum.kodi.tv/forumdisplay.php?fid=240)
+---- Thread: Refactor switching refresh rates (/showthread.php?tid=239262)
Refactor switching refresh rates - FernetMenta - 2015-09-18
I will move all resolution dependent code out of video renderer to guilib. The setting "pause during change of refresh rate" will disappear because it is silly having player continue playback during this time. Instead VideoPlayer will hook into windowing to OnDeviceLost and OnDeviceReset events of the IDispResource interface. Windowing has to know when a switch starts and when it is completed.
RE: Refactor switching refresh rates - Memphiz - 2015-09-18
Are we sure that the display is really ready to show content already when the OnDeviceReset is fired. Or might it be that the resolution and stuff like that is set but the display isn't showing pixels yet? Not sure if it is an HDMI standard when we get the OnDeviceReset callback.
Beside that sounds like a good idea
RE: Refactor switching refresh rates - FernetMenta - 2015-09-18
(2015-09-18, 10:57)Memphiz Wrote: Are we sure that the display is really ready to show content already when the OnDeviceReset is fired.
If those Events are used correctly, yes. I will rename them to OnDisplayLost/OnDisplayReset in order to reflect better what they are supposed to do. Applications also get events from the windowing system when they need to redraw.
RE: Refactor switching refresh rates - cyrano - 2015-09-19
Are you really sure of that?
My projector for example has a (very annoying) ~5s blackout when switching refresh rate. It's incredible that the designers of such expensive hardware consider that acceptable, but it's not uncommon from what I understand.
Even if it does signal that condition over HDMI, I'm doubtful that would survive every possible signal chain of switches, splitters, AVRs and video processors all the way back to Kodi.
RE: Refactor switching refresh rates - MrMC - 2015-09-19
Some type of adjustable delay needs to be present. OnDisplayLost/OnDisplayReset only tell when the display has been lost or gained in the OS, NOT when it is actually stable and usable. I have some HDTVs/Monitors that switch quick, some can take as long as 10 seconds to quit twitching and become stable yet the OS thinks everything is fine.
Refactor switching refresh rates - Memphiz - 2015-09-19
thats what i was after - i just didn't formulate it right
RE: Refactor switching refresh rates - brazen1 - 2015-09-19
I rely on 8 seconds worth of pausing refresh rate. Without it, the automated 3D switching time it takes my Samsung panel to get in the correct mode will lose the commands and never end up in the correct mode. It is picky and it is slow.
RE: Refactor switching refresh rates - FernetMenta - 2015-09-19
(2015-09-19, 13:45)MrMC Wrote: Some type of adjustable delay needs to be present. OnDisplayLost/OnDisplayReset only tell when the display has been lost or gained in the OS, NOT when it is actually stable and usable. I have some HDTVs/Monitors that switch quick, some can take as long as 10 seconds to quit twitching and become stable yet the OS thinks everything is fine.
If the delay is bound to the monitor, we should move it there. Then users can configure different delays for different monitors/projectors. Windowing needs to delay the OnDisplayReset event depending on the monitor connected.
RE: Refactor switching refresh rates - FernetMenta - 2015-09-22
current status: https://github.com/FernetMenta/xbmc/commit/3203529e4091f00adc1a4c17d49ec4f117ea1d49
VideoPlayer listens to OnLostDisplay/OnResetDisplay events and acts accordingly. Delay after changing refresh rate is moved to videoscreen. Windowing implementations can delay the reset event if desired.
RE: Refactor switching refresh rates - FernetMenta - 2015-09-24
Example how X11 does it: https://github.com/FernetMenta/xbmc/commit/b1c0ee6f1c2e8e1c1feadd6e5fdab2397d2be902