MpcVideoRenderer-DLSS5-1.4

MPCVR-DLSS5 1.4

Since 1.3 (3eb706e). Everything below was measured on an RTX 3050 with the tools in
tools/dlssnr_probe, and the numbers are theirs.

The two scaling lists grew, and are now ordered by what they measured

Upscaling and Chroma upsampling on the Settings page are shown best first, as measured
on 1080p film brought to 4K — not in the order the code happens to declare them. Each entry
carries its own number, so no setting already saved has moved.

Three entries join Upscaling:

Entry	What it is	1080p→4K luma, RTX 3050
ArtCNN C4F16 DS	four convolution layers in compute passes, doubles; cleans grain and compression as it enlarges	14.5 ms, 63 MB
FSRCNNX 16 AR	FSRCNNX_x2_16-0-4-1 with anti-ringing	18.0 ms, 190 MB
FSRCNNX 8 AR	FSRCNNX_x2_8-0-4-1 with anti-ringing	5.9 ms, 95 MB

Two join Chroma upsampling: Jinc (EWA), the polar kernel madVR and mpv call Jinc —
jinc(d) windowed by a jinc, cut at its third zero — and FSRCNNX 8 AR on Cb and Cr.

Nothing was taken away: every method that was there is still there.

Anti-ringing

A network asked to double a picture invents an edge steeper than the one it was given and
overshoots past it — the bright fringe along a dark line, which is what FSRCNNX is known for.
AR takes it back the way libplacebo does inside its own kernels: the value is pulled
towards the range the four source samples around that point really cover, four fifths of the
way. RAVU-zoom already carries this inside its kernel; FSRCNNX and ArtCNN do not.

	detail	overshoot	sharpness
FSRCNNX 8, line art	20.06 → 21.03 dB	0.00692 → 0.00189	0.911 → 0.821
FSRCNNX 16, line art	20.81 → 21.48 dB	0.01043 → 0.00248	0.931 → 0.835
FSRCNNX 8, clean film	48.13 → 47.99 dB	0.00015 → 0.00001	0.967 → 0.948

It costs nothing measurable in time.

Luma, ten 4K film frames reduced and enlarged again

PSNR on the most detailed quarter of the picture, against Catmull-Rom; halo is how far the
output overshoots the range the reference really covers along its edges.

Method	1080p→4K	grain	compressed	720p→4K	line art	halo	time
ArtCNN C4F16 DS	−1.36 dB	+1.37 dB	+0.38 dB	+0.20 dB	+2.92 dB	0.00028	14.5 ms
RAVU-zoom	+1.56 dB	+0.58 dB	+0.20 dB	+1.58 dB	+0.65 dB	0.00002	3.9 ms
FSRCNNX 16 AR	+2.02 dB	+0.31 dB	−0.02 dB	+2.27 dB	+2.43 dB	0.00005	18.0 ms
FSRCNNX 8 AR	+1.58 dB	+0.15 dB	−0.11 dB	+1.96 dB	+1.98 dB	0.00005	5.9 ms
FSRCNNX 16	+2.18 dB	+0.23 dB	−0.12 dB	+2.65 dB	+1.76 dB	0.00023	18.0 ms
FSRCNNX 8	+1.72 dB	+0.03 dB	−0.22 dB	+2.28 dB	+1.01 dB	0.00020	5.9 ms
Catmull-Rom	0	0	0	0	0	0.00000	0.9 ms
Jinc2m	−3.48 dB	−2.65 dB	−1.75 dB	−1.02 dB	+1.61 dB	0.00039	2.6 ms

A clean master is where FSRCNNX 16 wins and ArtCNN DS loses — ArtCNN is a denoiser as much as
an upscaler, and a clean reference has nothing to clean. A real film, grain and compression on
top, is the other way round: ArtCNN DS gains a decibel on everyone else, because it is the only
one that does not amplify what the encoder left behind. If you would rather keep the grain than
have it cleaned, take FSRCNNX or RAVU-zoom.

Chroma, six 1080p film frames through the filter itself

PSNR of Cb and Cr over the picture, then along the luma's edges where bleeding shows, against
Catmull-Rom. Measured with the chroma sited where video puts it, which is what decides this.

Method	Cb/Cr	at luma edges	line art, at edges	what it costs
Jinc (EWA)	+0.22 dB	+0.61 dB	+0.25 dB	about 32 texels a pixel, inside the conversion shader
RAVU-zoom	−0.05 dB	+0.47 dB	+1.89 dB	a pass of its own, 2.4 ms at 1080p
Catmull-Rom	0	0	0	16 texels a pixel
FSRCNNX 8 AR	−0.32 dB	−0.21 dB	+2.28 dB	a pass of its own, 4.0 ms at 1080p
Bilinear	−0.29 dB	−0.73 dB	−1.55 dB	one bilinear fetch

Jinc is the one to take on film: the only method above Catmull-Rom on both the colour and
the colour along edges, and it shifts nothing. On a 10-bit source it gains more still, +1.6 and
+2.0 dB. FSRCNNX on chroma is below Catmull-Rom on a photograph — a network trained on luma
has no business guessing colour from one — and the best of all of them on drawn lines by a wide
margin, which is the case it is there for. The list is ordered for film.

Defaults are unchanged: Upscaling is Jinc2m and Chroma upsampling Catmull-Rom for a fresh
installation.

Chroma rebuilt in 4:4:4 before the video processor

A new box, Replace VP chroma upsampling, sits under Chroma upsampling. With it on, a
compute shader rebuilds Cb and Cr with the chosen method and hands the D3D11 video processor a
4:4:4 picture — AYUV on an 8-bit source, Y410 on a 10-bit one — which the processor then
converts and resizes exactly as before.

The processor's own chroma measures about bilinear, and on a 10-bit source its driver reads the
studio range as 16/255 to 235/255 whatever the depth, which shifts the colour by about seven
tenths of a level:

Source	Chroma	Cb/Cr	At luma edges	Colour shift
8-bit (NV12)	the video processor	52.25	48.69	0.07 level
	Catmull-Rom before it	52.86	49.60	0.07
10-bit (P010)	the video processor	49.60	47.76	0.68 level
	Catmull-Rom before it	55.24	51.68	0.05
	Jinc before it	56.61	53.51	0.06

On a 10-bit film that is 5.6 to 7.0 dB on the colour, 3.9 to 5.8 dB along the edges, and the
driver's colour shift gone.

The processor keeps the picture, so what only it can do keeps applying:

• RTX Video HDR goes on working, and on a 10-bit source it starts working: the driver
  leaves a 10-bit 4:2:0 picture untouched (0.000 change) and tone maps the same frame in 4:4:4
  as it does an 8-bit one (37.7 against 37.9). It is no longer asked for on a 10-bit 4:2:0
  picture, where it never did anything, so the statistics stop claiming it there.
• Super Resolution does nothing to a 4:4:4 picture (0.000, against 4.0 on 4:2:0), so it is
  not requested for the pictures this moves, and the statistics do not claim it either.
• HDR passthrough is unaffected: the processor converts PQ from AYUV, Y410 and Y416 as it
  does from NV12 and P010.
• Interlaced video keeps the processor's own chroma: it alone deinterlaces, and only 4:2:0.

A setting changed while the film plays no longer freezes the picture

Ticking or unticking anything that stopped HDR output — RTX Video HDR first among them, or any
format change that took it away — froze the picture while the sound kept playing, and only
restarting the player brought it back. It was not what it looked like: HDR output needs the
flip presentation model, Swap effect: Discard asks for the older one, and Windows never takes
a window back to it. The swap chain then presented every picture, in time and without error,
while the screen kept the last one.

A window that has carried the flip model now keeps it — it shows everything the old model
showed. Reset() also took the HDR toggle lock before the renderer lock, the order every other
path takes them the other way round; that is fixed too.

Every setting now takes effect on the following picture, with no restart: the formats the
processor may take, RTX Video HDR, Super Resolution, the chroma and upscaling methods, and the
new box.

DLSS Super Resolution follows moving subjects

DLSS SR is fed motion vectors of its own instead of DLSS 5 NR's raw ones, which left still
backgrounds shimmering and grain along the frame's edges. Each block is drawn to the picture's
global motion where it lies within the noise of it, and a mean shift over the trusted blocks of
a 7×7 window, a sub-pixel search on the flow frames and a temporal blend follow the subjects in
the foreground. The option is marked (Experimental) in the page.

Under the hood

ArtCNN is made of compute passes, which the prescaler runner could not do: it now creates and
dispatches them, writing through unordered access slot 0 — the one slot feature level 11.0
always gives a compute shader. A compute pass sets no render target of its own, so a plane the
pass above had just drawn into stayed bound as one and Direct3D dropped its shader resource
view: the pass read zeros. It cost a black picture with ArtCNN and a green wash with FSRCNNX 8
AR on chroma before both ends were made to unbind. --tmpvport now checks ArtCNN as well, and
gives the harness's picture to the last half float.

Tools

playback_test --toggle changes each setting while the film plays, as the player does, and
watches the desktop itself — a renderer that draws every picture says nothing about what
reaches the screen. --gpu feeds it D3D11 textures the way a hardware decoder does, --hdr
runs it with HDR passthrough, --switch walks the processor's extras, and
--file <mkv> [--seek <s>] plays a real film through LAV. --chroma and --chroma10 now cover
every chroma method, each of them again through the video processor with the new box on.
--mainpage prints both scaling lists with the number each entry carries. shader444_test
compiles the generated chroma pass for every source format and chroma method. freeze_dump
reads what a frozen player is waiting for, with the filter's own names.