VideoRenderer icon indicating copy to clipboard operation
VideoRenderer copied to clipboard

The RTX HDR will to be breaking when zooming in frame size

Open ROG-EX opened this issue 2 years ago • 22 comments

The RTX HDR will to be breaking when zooming in frame size

ROG-EX avatar Jan 29 '24 12:01 ROG-EX

@emoose it will get wrong colors

ROG-EX avatar Jan 30 '24 11:01 ROG-EX

You need to provide more details in bug reports if you want to be taken seriously.

Press Ctrl+J to display debug OSD. Make screenshot before and after zooming.

And mention how you are zooming. I assume Pan&Scan?

clsid2 avatar Jan 30 '24 12:01 clsid2

It happens to me too, colors get blown out and the image becomes very contrasty (like if the HDR effect was applied twice) when zooming in with pan&scan (numpad 9). Here's a before & after:

2024-01-30 (2) 2024-01-30 (3)

nyakaspeter avatar Jan 30 '24 19:01 nyakaspeter

Can reproduce this but only after I force it to use NV12, with P010 it seems to be able to zoom in fine without colors breaking - maybe as a workaround you can disable NV12 in the video decoder settings and enable P010 instead?

E: seems with NV12 when zooming in NVCP starts to show HDR as inactive, resetting to default zoom with 5 then lets it reactivate, unfortunately don't think we really get any feedback to the renderer about whether HDR is active or not :/

emoose avatar Jan 30 '24 20:01 emoose

Does it also happen with SuperRes disabled?

Perhaps it also has certain requirements regarding video width/height? For example to be modulo 4.

Maybe also test if VideoProcessorGetStreamExtension still says that extension is available after a size change?

clsid2 avatar Jan 30 '24 22:01 clsid2

No difference with SuperRes disabled, tried resizing the video so that the Scaling : 1920x1080 -> *x* text would change too and HDR seemed fine with any dimension there.

Playing with the Video Frame settings, both Half Size/Normal Size work fine, while Double Size has the issue (with Scaling showing 1920x1080 -> 3840x2160)

Zoom 1 seemed fine at first, but with that resizing the player starts to make the issue appear, pretty strange though, 1920x1080 -> 2281x1283 works, but if I resize the player size by ~1 pixel the issue appears again - but the scaling text still shows the same 1920x1080 -> 2281x1283... Taking screenshot with ShareX does show that the inner size of the player changed from 2286x1282 (works) -> 2284x1282 (broken) though, but not sure how reliable ShareX measuring is.

Didn't check VideoProcessorGetStreamExtension yet but will try it soon.

emoose avatar Jan 31 '24 00:01 emoose

When I tried stretching the videos on both axes and moving them around with ctrl+numpad I observed that the colors go wrong when any of the the edges of the video go outside the window's frame. The actual size of the window doesn't seem to matter.

https://github.com/emoose/VideoRenderer/assets/43880678/07a1bef9-e0f3-413e-928b-f031c3324172

nyakaspeter avatar Jan 31 '24 01:01 nyakaspeter

Nice find, ~~I guess RTXHDR doesn't like it when part of the video is offscreen, darn (wonder if that's related to the issue in chrome where it disables/enables when scrolling at all)~~

Found a kinda hacky way to disable the HDR & reinit without the broken colors if the video is outside window bounds, maybe there's a better solution for it though:

void CDX11VideoProcessor::UpdateRenderRect()
{
	m_renderRect.IntersectRect(m_videoRect, m_windowRect);

	// RTX HDR doesn't like video being rendered outside window bounds
	if (m_bVPIsAutoHDRAvailable)
	{
		const bool bVideoOutOfWindowBounds = (m_videoRect.Width() > m_renderRect.Width() || m_videoRect.Height() > m_renderRect.Height());
		const bool bPrevAutoHDR = m_bVPUseAutoHDR;
		m_bVPUseAutoHDR = !bVideoOutOfWindowBounds;

		if (bPrevAutoHDR != m_bVPUseAutoHDR)
		{
			ReleaseSwapChain();
			Init(m_hWnd);
			InitializeD3D11VP(m_srcParams, m_srcWidth, m_srcHeight);
		}
	}

	UpdateScalingStrings();
}

Tried checking the Get/SetStreamExtension output for it too but seems those still return S_OK even when NVCP shows that its disabled itself, thanks NV..

E: looking into it some more it could be to do with shaders MPCVR uses for scaling:

https://github.com/emoose/VideoRenderer/blob/e2516d1b45533a8f609e0cbff232fbebefd5b280/Source/DX11VideoProcessor.cpp#L2837-L2844

Looks like when it's in window bounds then m_bVPScalingUseShaders is set to false, otherwise it's left as is, if I force bNeedShaderTransform to false there then I can move the video around top/left, but bottom/right stops anything displaying - HDR seems fine when it's past top/left though.

E2: ahh it's the format of the texture it uses when scaling, clsid2 had fixed it to a 10-bit format in their RTX HDR patch but I removed that part while I tried making it work, restoring that seems to let it work fine:

m_D3D11OutputFmt = (VPUseAutoHDR() ? DXGI_FORMAT_R10G10B10A2_UNORM : m_InternalTexFmt);

Will post a test build with that here shortly.

emoose avatar Jan 31 '24 02:01 emoose

Here's a test build with the change above: rtx-hdr-1.3-test2.zip

emoose avatar Jan 31 '24 03:01 emoose

Probably better to directly overrule the value of m_InternalTexFmt.

if (VPUseAutoHDR()) {
    m_InternalTexFmt = DXGI_FORMAT_R10G10B10A2_UNORM;
}
m_D3D11OutputFmt = m_InternalTexFmt;

Or if it also works with 16-bit:

if (VPUseAutoHDR() && m_InternalTexFmt == DXGI_FORMAT_B8G8R8A8_UNORM) {
    m_InternalTexFmt = DXGI_FORMAT_R10G10B10A2_UNORM
}

clsid2 avatar Jan 31 '24 07:01 clsid2

Here's a test build with the change above: rtx-hdr-1.3-test2.zip

With this build the issue is gone for me, both RTX SuperRes & HDR seem to work correctly when zooming in 👍

nyakaspeter avatar Jan 31 '24 09:01 nyakaspeter

Here's a test build with the change above: rtx-hdr-1.3-test2.zip

Thanks, it can work well with this build

ROG-EX avatar Jan 31 '24 10:01 ROG-EX

this not working correctly here: source is 720p but image is superres is set to 1080p and bigger. https://i.postimg.cc/sDpC4Mxz/image.png partial a user error but the result should still not happening. happens sometimes with 720p too.

and superres is not used anyway: bilinear: https://i.postimg.cc/1tzdxty8/image.png superres result bilinear: https://i.postimg.cc/zD4qjmkC/image.png

sdr works just fine.

mightyhuhn avatar Jan 31 '24 23:01 mightyhuhn

SuperRes does not support HDR. I think a check for that may have gone missing. It used to be disabled automatically for HDR.

clsid2 avatar Jan 31 '24 23:01 clsid2

pretty sure that's the major point of this driver update: image

edit: https://blogs.nvidia.com/blog/rtx-video-hdr-remix-studio-driver/ nope you are right.

mightyhuhn avatar Feb 01 '24 00:02 mightyhuhn

Yeah SR is disabled for HDR, if you change the SR settings in the MPC-VR setting window while it's playing that'll still try to enable it though, but likely won't work, maybe in future now they're focusing on HDR stuff they'll update SR to support it.

emoose avatar Feb 01 '24 00:02 emoose

it does not try for SD setting so maybe block it in general for now because it will fail spectacularly.

steps to reproduce. play a HDR file hat needs scaling i used 720p disable SR enable SR with more then SD. image is now washed out.

kinda shocked they didn't add it to be honest.

mightyhuhn avatar Feb 01 '24 00:02 mightyhuhn

At bottom of CDX11VideoProcessor::Configure() add !SourceIsHDR() check before enabling SuperRes.

clsid2 avatar Feb 01 '24 13:02 clsid2

@emoose dithering and RTX HDR can work correctly on HEVC 10-bit file with your rtx-hdr-1.3-test2 build but not 0.7.3.2210 or 0.8.0.2215 (HEVC 8 bit file is ok)

dbz400 avatar Mar 19 '24 15:03 dbz400

You need to report that here: https://github.com/Aleksoid1978/VideoRenderer

But afaik RTX HDR is skipped for 10bit because it didn't always work properly.

clsid2 avatar Mar 19 '24 15:03 clsid2

Thanks @clsid2 .Just report there.

dbz400 avatar Mar 19 '24 15:03 dbz400

Still having issues even with the new fix. However turning off NV12 does seem to help, but it also seems to loose all HDR effect. I am not sure what's going on here.

jmsether avatar Apr 09 '24 02:04 jmsether