MpcVideoRenderer-DLSS5-1.6

MPCVR-DLSS5 1.6

Since 1.5 (726377e). Everything below was measured with the tools in tools/dlssnr_probe,
on an RTX 3050, and the numbers are theirs.

Sharpening

The filter could enlarge finely and could not sharpen at all. A film already at the screen's
size, or enlarged by the hardware video processor, had no way to gain definition here. There is
now a Sharpening list on the Settings page with two methods and five levels, run after the
resize so it reaches a film at any size. Subtitles are drawn after it and are never sharpened.

Adaptive-Sharpen is bacondither's mpv shader (2021-10-17, BSD 2-clause) ported to HLSL: it
weighs each of 25 neighbours by how active its own area is, sharpens blurred edges most and
steep ones least, and limits the result with a tanh rather than a hard clip.

Unsharp + Clamp is a 3x3 high pass pulled back towards the range the four neighbours really
cover — the principle of AviSynth's LimitedSharpenFaster, and the same clamp the anti-ringing
upscalers already use here.

What each one is worth

Ten 4K frames halved, degraded the way a source is, enlarged again, sharpened, and scored
against a reference none of them saw (dlssnr_harness --tsharpen). Every method is read at
the strength that brings it to the same edge gradient: comparing each at its own best
compares six different amounts of sharpening and says nothing about the sharpeners. halo is
the mean overshoot past the range the reference really covers along its edges, x1000; grain
is the fine detail left in flat areas, output over reference.

Method	psnr-d	halo	grain	grain source	compressed source	time, 4K
no sharpening	43.93	0.048	3.698	39.53	37.97	—
Adaptive-Sharpen	44.93	0.076	3.597	39.37	37.92	3.05 ms
Unsharp + Clamp	44.91	0.051	3.926	39.15	37.81	0.57 ms
unsharp, no clamp	44.94	0.098	4.705	39.10	37.79	0.57 ms
CAS	44.86	0.055	3.842	38.64	37.62	0.64 ms
CAS + the same clamp	44.75	0.052	3.824	38.77	37.64	0.83 ms
RCAS (FSR 1)	44.73	0.055	3.901	38.63	37.62	0.51 ms

The two that ship are the two ends of one trade. Adaptive-Sharpen is the only one that does
not amplify grain — on a clean master it leaves less fine detail in flat areas than doing
nothing — and on the two sources that matter, grain and compression, it costs almost nothing:
0.16 dB and 0.05 dB, where the next best costs 0.38 and 0.16. It is also five times the price
and rings half again as much on a clean picture. Unsharp + Clamp has the lowest ringing of
all, at the level of the unsharpened picture itself, and is second everywhere for a fifth of
the time.

Sharpening the colour as well as the luma was measured and dropped: it moves the result by less
than 0.3 dB and the sign turns with the source. Both passes move the luma only, by adding one
number to R, G and B alike, which leaves B−Y and R−Y exactly as they were.

The five levels

A level means the same amount of sharpening whichever method is chosen. The two are not on the
same scale, and neither is on the scale of the comparison above — a picture halved and enlarged
again is far softer than anything this renderer produces. The levels are calibrated through the
filter itself, on a 1080p film enlarged to 3200x1334, as the gain in mean gradient each one
really buys:

Level	gain in detail	Adaptive-Sharpen	Unsharp + Clamp
1	+4 %	0.22	0.45
2	+8 %	0.33	0.62
3 (default)	+13 %	0.46	0.83
4	+20 %	0.68	1.17
5	+28 %	0.99	1.49

Measured back through the filter, level 1 gives +3.7 % and +2.8 %, level 3 +13.2 % and +13.0 %,
level 5 +28.3 % and +27.9 %. Level 3 is the +13 the quality measurements settle on; 4 and 5 are
past it, for a taste rather than for fidelity.

Super Resolution asked the same way in both places

Ticking Use for resizing did not turn RTX Video Super Resolution on, while picking the same
value again from the list did. Two code paths were asking different questions:
InitializeD3D11VP refused the extension unless the picture was on its way to an 8-bit target
or RTX Video HDR was making the HDR, while Configure() asked without that test. So every HDR
film and every 10-bit source got it only by way of the list.

The refusal cost something real: on a PQ BT.2020 source in P010 the driver changes the picture
by 3.928 when the extension is enabled, against 3.903 on the same frame in SDR — it does the
work there as well as anywhere. Both places ask the same question now, and it is that one.

A picture that stops while the sound plays on

Reported on a 24 Hz TV: a very fast pause and play, and the picture stops while everything else
carries on. It took a bench that drives MPC-HC itself to see it — the renderer's own graph never
shows it — and the stacks of the frozen player to place it.

The fault turned out to be the audio renderer's clock, not this one. Every picture is
scheduled against the reference clock the graph gets from one of its filters; with one
third-party audio renderer that clock stops while the sound goes on playing, so each picture
looks one frame further into the future than the last and playback slows to a crawl. Swapped
for MPC-HC's own audio renderer the incident does not happen at all, and the sync offset stops
wandering — it sits between −19 and −5 ms instead of reaching +30.

The renderer is no longer dragged down with it:

• a picture's turn is waited for with a bound. A turn cancelled after it was given used to leave
  the streaming thread waiting for ever, ten seconds at a time; it is now taken instead.

• a clock caught not moving between two such turns is treated as stopped, and the pictures are
  paced by the stream's own frame duration until a turn arrives again. Render ahead's hold is
  skipped meanwhile, since the pacing is already the renderer's.

• the statistics name the clock, and say when it has stopped:

  Frames  : 101, skipped: 0/0, failed: 0, turns late: 27 (turn +254 ms, clock +636 ms, base +0 ms)
  Clock   : MPC Audio Renderer
  

  turns late and turns lost stay at zero on a clock that keeps time. When they move, the
  first thing to try is another audio renderer. The manual has the detail.

A refused swap-chain resize is also answered now instead of ignored: a flip model swap chain
that does not match its window presents every picture without any of them reaching the screen,
which from inside the renderer looks like nothing at all. It is rebuilt, and the statistics
count how often that was needed.

None of it costs anything while the clock runs: sync offset −6.5 ms with render ahead and −7.0
without, no pictures skipped, state changes instant, across the whole playback battery.

Also

• the bench can drive the installed MPC-HC, tap the space bar twice with a chosen gap, and read
  the screen by duplicating the desktop — the only way to see what a flip model swap chain
  really put there. It checks that it can tell a stopped picture from a running one before it
  claims anything.
• a frozen player's threads now say what they are waiting for, in their own descriptions, which
  a report reads across processes.

x64 and Win32, zero warnings.