View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000633||madVR||bug||public||2020-01-29 19:05||2020-02-29 15:35|
|Summary||0000633: madVR + Kodi DSPlayer: Bug with vertical shift (only) when video is playing in background (Home Screen)|
i made multiple screenshots which should easily illustrate the problem with some examples.
Download of all screenshots in one ZIP:
(The sreenshots were created on my office system - so please don't wonder why frame rate switching etc. is not enabled)
It happens consistent on every test system with Kodi DSPlayer + madVR i tried. No matter what OS, GPU or LAV Filters version (both internal and external) is used.
At first i had in mind that this bug could be fixed in Kodi DSPlayer itself, but since i'm maintaining an updated Kodi DSPlayer x64 version for some time now i found no hint in the source that it could be a problem in Kodi DSPlayer itself.
My best guess would be that it's a problem regarding the communication of the desired scaling and vertical shift parameters between Kodi and madVR. (?)
The communication between Kodi and madVR seems to work incorrectly when Kodi is on home screen while playing the video in the background rather than being in VideoFullScreen/VideoOSD where everything seems flawless and rock solid. (even when combining zoom and vertical shift. No problems here whatsoever!)
If you need more input or information, don't hesitate to let me know.
This bug is the only problem we encounter on our many DSPlayer x64 + madVR setups i setup for me or friends with higher end projectors (Sony VW 570).
Although i know it's mostly a cosmetic GUI issue, it would be great if we could find a way to fix this.
It would really enhance the final "retail-ish" GUI experience of the otherwise great software combination of DSPlayer + madVR.
Thanks very much.
...and greetings from the AVS FORUM hdr2sdr thread! :-D
|Additional Information||Side note:|
I don't know if you ever use Kodi DSPlayer these days, but since you are the original author of the very old Kodi GUI scaling cristism ( https://forum.kodi.tv/showthread.php?tid=200401&pid=1757094#pid1757094 ), you may want to have a look here:
This is an updated DSPlayer x64 build with better GUI scaling which we use on many systems without problems while using HDR 2 SDR tone mapping.
Example of the fixed GUI: http://nakunana24519x.bplaced.net/_tmp/k-bettergui/pixelation_example_22353425.png
(Just to make it clear:
The described bug of this ticket happens on all builds of Kodi DSPlayer, so it's not an issue of the updated build)
|Tags||No tags attached.|
|madVR Version||v0.92.17 final, madVRhdrMeasure113|
|Media Player (with version info)||Kodi DSPlayer x64|
|Splitter (with version info)||LAV Filters 0.74.1|
|Decoder (with version info)||D3D11 -> Automatic (Native)|
|DXVA2 Scaling Active||no|
|Aero / Desktop Composition||On|
|Problem occurs with mode||all modes|
|GPU Manufacturer||AMD + Intel|
|GPU Model||RX 580 (Win 10 x64), Intel GPU (Win 7 x64)|
|GPU Driver Version||All|
I think the problem is that madVR tries to interpret what the media player wants (zoom, AR and shift), and fails to do so properly in this specific case. The reason why madVR tries to interpret the media player wishes is that madVR automatically detects black bars in the image and zooms them away and also supports CIH, CIW and CIA front projection setups (if the user has activated these features in the madVR settings).
Have you already seen this document?
It's quite old, but still applies.
You say you're maintaining a DSPlayer build - does that mean you're a developer and can also do changes (at least minor ones)? If so, if it's not too difficult, it would be great if you could teach DSPlayer to communicate its wishes to madVR clearly, by using the madVR communication interfaces. See 1c) in the PDF above. I believe that would fix all the issues.
Thanks for the unexpected fast reply and the PDF (which i have not seen before).
Black bar detection ("automatically detect hard coded black bars" is disabled on the test setup. (madVR "zoom control" settings tab all checkboxes unchecked)
I tried finding a workaround and did experiement with all settings i thought might do the trick.
Could not find any workaround in the end.
Now that you know that this happens while "automatically detect hard coded black bars" being disabled, does that change any of your assumptions?
So if i understand correctly, it looks like my wary suspision was correct, that in case of the existing DSPlayer, madVR interprets what the user has set in DSPlayer and acts on it (zoom/ar/shift) and Kodi itself is _not_ telling madVR what to do by sending commands to it or something like that.
I tried to think about what is different when Kodi has the video playing in the background rather then playing it in VideoFullScreen/VideoOSD (where madVR interprets everything flawless as it seems).
When VideoFullScreen/VideoOSD is used in Kodi, there is not even a "videowindow" control-tag in the Kodi skin, because it's most likely is all done by the Kodi core.
As soon as you switch to the home screen while playing video, the skin uses a very simple <control type="videowindow"></control> where the video is then displayed.
Looks like madVR does not get the information (zoom/ar/shift) it wants from this somehow "other" video player window.
As you can see it in the screenshots madVR seems to get _some_ information (even if they end up wrong) from the "background-video", because if that would not be the case you would assume that the background video maybe just would be displayed without any zoom/shift at all, but at least always be of correct AR.
I'm not really a C developer, but coming from the ux/ui/qa/web-dev world i have some background in coding php/js.
I have a machine set up which is able to compile DSPlayer x64 successfully.
I did create the build with the fixed/better gui scaling via mipmapping for Linux and Windows and was able to add some smaller(!) changes and backports to make DSPlayer a little more future proof.
I checked 1c) of the PDF and seem to understand your intent regarding implementing SetDestinationPosition/SendCommandX to have Kodi always tell madVR exactly and directly what Kodi wants to avoid the misinterpretation in this background-video-case.
Although i'm not shy of the work hours and happy to have a further look into the DSPlayer code, i have to assume that such more videoplayer related programming will be above my abilities.
In case i can't implement this on my own, do you have any further assumptions why madVR interprets DSPlayers user zoom/ar/shift flawless (even in the most exotic combinations) when being VideoFullScreen/VideoOSD in opposition to the video playing in background?
The discrepancy of the flawless interpretation on the one hand and the messup on the other hand is what really irritates me.
IF madVR's interpretation in VideoFullScreen/VideoOSD would also only be "mostly correct, but still not flawless" i would think that implementing IMadVRCommand::SendCommandStr would most likely be the only clean and rock solid way to go.
But at this point i would still have hope that we may find a way to change whatever is different in Kodi when the video is playing in background so madVR acts exactly like it does when playing in VideoFullScreen/VideoOSD.
So far for my quick feedback.
As said, i'm happy to have a deeper look at the code, but i don't want to get my/our hopes up about me implementing SetDestinationPosition/SendCommandX. :-/ :-)
Thanks again for your time.
madVR tries to interpret the media player wishes by looking at things like changes to the rendering window size, changes to the parent window size, and calls to IVideoWindow::SetWindowPosition etc. Depending on these things, and the timing and order of changes to these properties, madVR tries to "understand" what the media player wants to achieve. And usually that works reasonably well, but occasionally it may fail. I assume if not the full screen is covered with the video, it makes things more difficult for madVR to understand fully.
I'm not sure if you can fix this by just playing around with the current code. I think you would waste a lot of time doing that. It would be more effective if you tried to use the madVR "SendCommandStr" API. It can't imagine that it would be very difficult. I think the key things you would have to do are:
1) Locate all code places in DSPlayer which call IVideoWindow::SetWindowPosition.
2) Find a way to access IMadVRCommand at all the same code places.
3) Try to understand the IVideoWindow::SetWindowPosition code. How does DSPlayer call the numbers to feed into SetWindowPosition? I assume DSPlayer will access the DSPlayer settings and then do some math to calculate the numbers.
4) Based on your understanding of 3), call SendCommandStr() with the appropriate zoom mode.
I'm not sure which of these 4 things will be the most difficult to achieve. In theory they could all be easy. Or difficult.
Thanks for the guidance.
Before your update note i already made some first searches regarding the code places of SetDestinationPosition.
With your further hints and proposed steps (especially mentioning to focus on SetWindowPosition, not SetDestinationPosition) i have some success to report.
I made a test build with some kodi debug notifications to understand when and which area of the code triggers.
After some hours of getting used to the new area of programming and code i now have some first test builds which already go in the right direction.
I'm now using multiple SendCommandX which are also documented in the mvrInterfaces.h file.
Just a code snippet to get a feel of what i'm trying:
if (Com::SmartQIPtr<IMadVRCommand> pMadVrCmd = m_pDXR)
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_ViewMode != ViewModeOriginal)
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_ViewMode == ViewModeNormal)
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift > 1.0)
pMadVrCmd->SendCommandDouble("setZoomOffsetY", -(1.0 - CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift));
else if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift < -1.0)
pMadVrCmd->SendCommandDouble("setZoomOffsetY", (1.0 + CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift));
CGUIDialogKaiToast::QueueNotification(CGUIDialogKaiToast::Info, "DSPlayer", "madvr debug", TOAST_MESSAGE_TIME, false);
This direction of progress already results in a stable and predictable madvr video on homescreen with correct vertical shift and zoom. (Not possible before outside Kodi videofullscreen/videoosd window)
As we hoped for, madVR now strictly follows what is set above, no matter in which kodi window the video is displayed.
Still some work to do though. The custom video "pixel ratio" setting is not implemented yet for example.
Will report further on progress or roadblocks. :-)
Questions for the meantime:
Let's say everything works out as discussed regarding adding robust zoom/vshift/originalsize-mode/custom-aspectratio support - there is one thing i don't know if i have to account for it in the code:
I have absolutely no experience on how original Kodi or even DSPlayer-Kodi-madVR handles 3D.
Do i have to account for anything in that regard?
My only experience with home cinema 3D content is on retail hardware players with retail 3D BD.
Is madVRs "setArOverride" what should be used to adapt the Kodi optional custom video "pixel ratio" feature/setting?
Or is this the wrong approach and should i maybe just use additional conditions for setZoomFactorX/Y instead?
Something like this seems to work to adapt the setting:
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio != 1.0)
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio < 1.0)
pMadVrCmd->SendCommandDouble("setZoomFactorX", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount * CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio);
else if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio > 1.0)
pMadVrCmd->SendCommandDouble("setZoomFactorY", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount * CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio);
Glad to hear you made good progress! :-)
I assume (hope) that Kodi's "pixel ratio" option has a default value which is something like "auto detect" or "don't change" or something like that? I think using "setArOverride" is preferred over adjusting the zoom factors manually, because really this option sounds like it's primary purpose is to modify the AR, right? The end effect might be the same, though. Still, I tend to prefer "setArOverride" in this case.
I'm not completely sure about 3D content in this case. I'd suggest that you start by ignoring it and treating it like 2D. If that doesn't work for some reason just let me know, then we can brainstorm about it.
Btw, great work on the improved downscaling, it's really hard for me to understand how the Kodi main devs don't seem to feel a need to fix this.
I don't suppose you managed to port DSPlayer to Leia? Last time I checked it still seems to be stuck on the previous release.
Here we go with a test build. :-)
I also handed it to a friend and will throw some everyday-testing at it myself:
Edit: Removed old links
custom video pixel ratio:
Yes, Kodi's per video custom video "pixel ratio" defaults to 1.0 (which is the neutral value doing nothing) and the setting itself is just another simple per-video setting like "zoom".
According to the wiki it's just a correction option for videos which have a messed up AR for example.
The slider ranges from 0.5 to 2.0
0.5 results in 50% image width while keeping the height untouched, meaning: keeping height at whatever size it's already at
1.0 is neutral and changes nothing
1.5 results in 150% image height while keeping the width untouched, meaning: keeping width at whatever size it's already at
2.0 results in 200% image height while keeping the width untouched, meaning: keeping width at whatever size it's already at
For now i went with the setZoomFactor implentation for the setting. It just seemed to work so solid and my previous attempts at using "setArOverride" instead ended up not working correct for some reason.
Is there some more background info regarding on which "setArOverride" values are allowed and what they will do exactly in order to maybe achieve the above mentioned?
It seemed like i ended up with a blank black video if "setArOverride" has been set to a value it did not seem to like.
I'm open to changing the implementation to "setArOverride" if i know how. :-)
Let's ignore it for now and hope that it's not affected by the changes.
I already asked in the DSPlayer thread if someone is willing to test 3D on an old DSPlayer+madVR build vs the new build.
Maybe this confirms easily if 3D works as good (or bad) as before. I think this is all we would want to know.
I'll report if i found some willing testers.
||Sorry, no time to test the test build, unfortunately. I'm extremely busy working on the Envy atm. However, based on your description of the Kodi "pixel ratio" feature, I'd say that probably using "setZoomFactor" is a good choice instead of "setArOverride". So I think you should just leave it like that.|
No worries, just wanted to post it here for informational/archival purposes.
Okay, let's keep the setZoomFactor variant at least for now then.
Thanks for the input, i'll just update when there is further feedback or progress.
Good look with your work on the Envy.
Just for the archives:
From now on, builds with the implemented correct "API-communication" solution (and some more changes/backports/fixes for other stuff) can be found here:
Kodi 17.7 DSPlayer x64 BETTERGUI
||Great stuff - thanks!|
I got so used to the fixed "non-picture-squeezing" behaviour that i'm now irritated when i have to use an old build for a short time for debug reasons. :-)
Regarding 3D feedback after API-picture-size-stuff changes:
I got not much but some feedback by 2 users which sounded like 3D works as before. (Since our goal was to not brake it or make it worse, it should be okay.) Would have preferred to test myself also, but since that's not an option...
Bonus question while working on some additional stuff for DSPlayer:
In regards of DSPlayer<>madVR i was wondering about the "preset queue" setting:
- Preset queue (windowed+exclusive) is set to 8 (default) via madVR tray settings
(rendering->windowed mode, rendering->exclusive mode)
- The madVR-overlay shows that it uses the setting of 8 correctly (x/8)
When Kodi DSPlayer has _any_ own GUI element showing on top of the playing madVR video, madVR changes the "present queue" maximum count temporarily from 8 to 2 - as long as DSPlayer shows said GUI elements. (See screenshots)
As soon as all Kodi-GUI elements are hidden again, the temporary reduced count jumps back to 8 instantly.
Just to be sure: I'm not talking about how filled the present queue is, but shown maximum count x/8. It jumps to x/2 for the temprary situation.
Is this bevaviour intentional and maybe unavoidable for some technical reasons?
- I suspect this behaviour is handled from inside madVR itself, since my build of DSPlayer does not set any "preset queue" setting
- I cleaned the build of being able to change madVR settings. Everything is configured via madVR tray settings. Besides the discussed picture-size-API-stuff DSPlayer does not "control" madVR in any further way anymore.
||It's intentional. Having a queue size of 8 means that for 24fps, that would be 333 milliseconds latency/delay. So you press a key to move the Kodi "cursor"/focus, and it takes 333+ milliseconds for that to become visible. That's not good, of course, which is why madVR limits that to 2 frames when any active GUI is visible, to make GUI feel less sluggish.|
1) I'm aware of the typical sluggishness in 23hz/low-fps scenarios which feels about identical on all devices (apple tv 4k @ 23hz, kodi devices @ 23hz etc.)
In the discussed matter we are talking about an additional "present-queue"-delay which would add even on top of the known typical 23hz-sluggishness - do i understand that correctly?
2) Is this implementation Kodi DSPlayer specific?
3) Would it be possible to consider a future madVR setting for DSPlayer to use like:
Variant A (most simple but already very helpful):
Variant B (more flexible):
m_pSettingsManager->SetBool("preRenderFramesReductionOnGUI", true); // Should be true by default, of course.
int framesCount = 3;
m_pSettingsManager->SetInt("preRenderFramesReductionOnGUICount", framesCount); // Purely optional override of the default value of 2
There would be _no_ need for a setting in the madVR-settings-UI itself. The existence of any option itself to be used by DSPlayer code would be very sufficient.
Besides having control for special use cases there are higher end 21:9 projection screen users which for example use a standard projector resolution of 3840x2160 while using a Kodi skin with additional features to mask all the visible content which is outside of their 21:9 screen.
These features are therefore detected as GUI by madVR which leads to these users being stuck with an absolute maximum present queue count of 2.
Besides this example i can think of more use cases which would make Kodi show GUI permanenty on top of a playing video while there is no user input/navigation going on.
> do i understand that correctly?
> Is this implementation Kodi DSPlayer specific?
> Would it be possible to consider a future madVR setting
You already have some control over it. Please check "mvrInterfaces.h". If you search for "low latency" you'll find what you need.
|2020-01-29 19:05||justsomemadvrdude||New Issue|
|2020-01-30 10:31||madshi||Note Added: 0002628|
|2020-01-30 13:43||justsomemadvrdude||Note Added: 0002629|
|2020-01-30 15:03||justsomemadvrdude||Note Edited: 0002629|
|2020-02-03 12:41||madshi||Note Added: 0002632|
|2020-02-04 00:49||justsomemadvrdude||Note Added: 0002633|
|2020-02-04 01:55||justsomemadvrdude||Note Added: 0002634|
|2020-02-04 01:56||justsomemadvrdude||Note Edited: 0002634|
|2020-02-04 03:06||justsomemadvrdude||Note Edited: 0002634|
|2020-02-04 03:07||justsomemadvrdude||Note Edited: 0002634|
|2020-02-04 03:18||justsomemadvrdude||Note Edited: 0002634|
|2020-02-04 03:30||justsomemadvrdude||Note Edited: 0002634|
|2020-02-04 03:35||justsomemadvrdude||Note Edited: 0002633|
|2020-02-04 03:36||justsomemadvrdude||Note Edited: 0002634|
|2020-02-04 08:55||madshi||Note Added: 0002635|
|2020-02-04 09:01||madshi||Note Added: 0002636|
|2020-02-05 17:19||justsomemadvrdude||Note Added: 0002640|
|2020-02-05 17:27||madshi||Note Added: 0002641|
|2020-02-05 17:27||justsomemadvrdude||Note Edited: 0002640|
|2020-02-05 17:34||justsomemadvrdude||Note Added: 0002642|
|2020-02-05 17:34||justsomemadvrdude||Note Edited: 0002642|
|2020-02-05 18:25||madshi||Note Added: 0002643|
|2020-02-07 13:10||justsomemadvrdude||Note Edited: 0002640|
|2020-02-22 00:12||justsomemadvrdude||Note Edited: 0002640|
|2020-02-22 00:16||justsomemadvrdude||Note Added: 0002677|
|2020-02-22 00:38||madshi||Note Added: 0002678|
|2020-02-29 13:12||justsomemadvrdude||Note Added: 0002681|
|2020-02-29 13:28||madshi||Note Added: 0002682|
|2020-02-29 15:10||justsomemadvrdude||Note Added: 0002683|
|2020-02-29 15:11||justsomemadvrdude||Note Edited: 0002683|
|2020-02-29 15:13||justsomemadvrdude||Note Edited: 0002683|
|2020-02-29 15:14||justsomemadvrdude||Note Edited: 0002683|
|2020-02-29 15:35||madshi||Note Added: 0002684|