MPCVR-Plus 1.8

MPCVR-Plus 1.8

Since 1.7 (0115c41). Two things about scaling, both of them cases where the page named one
method and another one ran.

The upscaler named in the list is the upscaler that runs

A film at 1920x1038 shown at 2496x1349 was enlarged by Catmull-Rom while the list went on
saying FSRCNNX 16 AR, and the chosen method only took over at 2497x1350.

Every one of these networks carries mpv's //!WHEN clause, which asks whether it is worth
starting at the size the window happens to want: FSRCNNX and ArtCNN want 1.3x, RAVU-zoom
wants the picture to be growing at all. 1920 x 1.3 is 2496 — the reported number exactly.
Below it the network stood aside and the fallback took the picture, and that fallback is
Catmull-Rom for every one of them.

The question is now put at the network's own scale rather than at the window's, so the method
named in the list is the method that runs, at any enlargement however small. Nothing
structural is bypassed: both conditions these shaders carry are "is it worth it", never "can
it". At the reported sizes, per frame on an RTX 3050 — FSRCNNX 8 10.0 ms, RAVU-zoom 6.6,
ArtCNN 19.5, FSRCNNX 16 AR 22.1. It costs the same at every ratio, because the work is the
same: the network doubles the source whatever the target is.

The Downscaling method reduces at every ratio

Use the "Upscaling" method to reduce the frame to 50% is removed. A 2x network asked to
reduce has to double the source first and bring the picture down from that: on a 4K film in a
1080p window that had FSRCNNX 16 working at 7680x4320 for 93.4 ms a frame, with the sync
offset out to +5 s and 18 frames late. The option could not be made to mean what it says
without being unusable exactly where it was meant to help.

So the Downscaling list now reduces at every ratio, which is the one thing it can be relied
on to say. Nothing is lost for the classic kernels, which is what that option really chose
between.

Spline36 for downscaling

New in the Downscaling list: the piecewise cubic of Avisynth's Spline36Resize, which mpv
carries as its spline36 kernel. It sits at the end of the list rather than in quality order,
because that list saves the position it is sitting on.

A downscaler is judged on how much of what it may keep it keeps, and how much of what it must
throw away folds back as aliasing. Frequency response in cycles per output pixel, passband to
0.5, where 1.000 is "kept whole" and anything above it is overshoot — ringing, not detail:

kernel	0.125	0.250	0.400	worst above 0.5
Box	0.974	0.900	0.757	0.624
Bilinear	0.950	0.811	0.573	0.389
Hamming (default)	0.969	0.881	0.720	0.582
Bicubic	0.996	0.939	0.716	0.470
Bicubic sharp	1.067	1.125	0.861	0.453
Lanczos	1.004	1.011	0.823	0.466
Spline36	1.000	0.995	0.792	0.452

Spline36 is the only one flat where it matters. It does not soften the way Hamming and Bicubic
do, it does not invent contrast the way Bicubic sharp and Lanczos do, and it still rejects more
of what folds back than either. Bilinear rejects most of all and gives away a fifth of the
detail at a quarter of Nyquist for it.

Said plainly: those numbers are computed from the kernel definitions by numeric integration,
not measured through the shipped shader. The shaders are a direct transcription of them. What
is measured is that it loads and runs — 2560x1440 -> 1920x1080 Spline36, nothing skipped.

Hamming stays the default, because it is upstream's.

Also

• playback_test --scalers --size WxH --window WxH sweeps every upscaler at a ratio you pick,
  which is how the 1.3 threshold was caught.
• --tmpvport still passes, 0 checks failed: the gate moved, the arithmetic did not.

x64 and Win32, zero warnings.