videos with some specific frame rates flicker with tscale=box --vo=gpu-next

[aufkrawall]

E.g. this sample from the Kodi wiki exhibits black flicker:
https://drive.google.com/file/d/0BwxFVkl63-lEUGZnR1JHUUU0WEk/view?resourcekey=0-YrNv_pEiY4Ukaw_X5rckRw

It seems to be specific to --tscale=box, e.g. linear doesn't trigger it. Other mpv settings don't seem to matter.

Used mpv-x86_64-20211107-git-ec16769 build by shinchiro.

Log:
output.txt

[haasn]

I think the correct solution here is disabling the use of tscale=box for interpolation (or hard-coding it as being equal to --interpolation=no).

box is sort of special because it's the only filter window that only spans a single sample, which breaks some of the assumptions in the code. I don't see why you would use it as an interpolation kernel anyways - it's just nearest neighbour which is the same as what you get with interpolation disabled.

Thoughts?

[aufkrawall]

Indeed with gpu-next, box looks like no interpolation at all.
However, with --vo=gpu, it looks smooth. I've been using it as follows with gpu:

tscale=box
tscale-window=sphinx
tscale-radius=1.0
tscale-clamp=0.0

I admit that I didn't check how each parameter turn out or if they make that much sense at all. It was posted in the lengthy dicussion which parameters for interpolation would be "best". I found this to look smoother than linear, while being less blurry than any cubic kernel. I'd really like to preserve that result with gpu-next.

[hooke007]

For gpu-next:

tscale=sphinx # or 'quadric'
tscale-clamp=0.0

[aufkrawall]

It's really blurry vs. "old tweaked box". I also tried with otherwise the same parameters, but old vo=gpu box result always (I tried multiple times to rule out screen capture in an unfavorable moment for either setting) has far less ghosting and motion blur:

[haasn]

Try something like --tscale=sphinx --tscale-radius=1.0 --tscale-blur=0.6991556596428412. (Or maybe the tscale-radius option is unnecessary, I'm not quite sure off the top of my head)

At any rate, it should be possible to recreate the exact same filter kernel without the tscale=box hack, which was always just an ugly work-around for an mpv shortcoming in my mind.

Alternatively I could reintroduce something that replaces the old tscale=box, like perhaps tscale=flat that's constant 1 everywhere.

[aufkrawall]

Thank you. I've found

tscale=sphinx
tscale-radius=0.49
tscale-blur=0.6991556596428412

to work great (fingers crossed :) ):

With tscale-radius=1.0, it once again looks stuttery. Funny: With 0.5, it shows the black flicker issue. Values like >=0.7 work, but are already too stuttery.

Edit: Btw: Is it technically possible to have a tscale filter for interpolation that also works in gpu-dumb-mode? E.g. something lightweight like linear?

[haasn]

Edit: Btw: Is it technically possible to have a tscale filter for interpolation that also works in gpu-dumb-mode? E.g. something lightweight like linear?

Technically possible. But note that every device that supports vulkan also supports non-dumb mode, so I don't see the reason to enable it.

[aufkrawall]

Technically possible. But note that every device that supports vulkan also supports non-dumb mode, so I don't see the reason to enable it.

I'm not sure if it is actually caused by not being in gpu-dumb-mode anymore or due to the additional load, but when I try to use interpolation with tscale=linear, performance on my weak Gemini Lake Intel GPU totally breaks down (already did so with old --vo=gpu). It is also massively overwhelmed by e.g. bicubic_fast image scaling.

Well, at least video-sync=display-resample already does the trick with some refresh rate switching. Massively underrated feature outside of mpv user base. :)

Btw: I'm stupid: tscale-radius <0.5 is out of range. With the default tscale-radius value of tscale=sphinx, tscale-blur=0.65 looks good to my eyes.

[haasn]

Note that bicubic_fast is a lot faster with --vo=gpu-next than with --vo=gpu, since it only does two passes (one for scaling both chroma planes and RGB conversion, one for main RGB scaling) versus vo_gpu's four (chroma merging, chroma scaling, RGB conversion, main scaling).

You should also note that dumb mode is no longer really a thing in --vo=gpu-next because libplacebo is, well, less dumb. Basically, --gpu-dumb-mode=no is identical to --gpu-dumb-mode=auto with --vo=gpu-next, because it will always skip unnecessary passes (anything otherwise is a bug).

What setting --gpu-dumb-mode=yes does is effectively just disable FBOs completely (and any features that depend on it).

[aufkrawall]

Thanks for sharing that technical background information. With --gpu-api=vulkan in --vo=gpu, this SoC draws a bit more power than with OGL. This GPU is just extra terrible (current Firefox Webrender makes it explode...), I'll report back how it fares with gpu-next. =)

[hooke007]

since it only does two passes (one for scaling both chroma planes and RGB conversion, one for main RGB scaling) versus vo_gpu's four (chroma merging, chroma scaling, RGB conversion, main scaling).

(Maybe it's offtopic, but I suddenly thought of it) gpu-next seems to avoid the issue #5727 in vo_gpu, which would make a little performance waste.

[haasn]

since it only does two passes (one for scaling both chroma planes and RGB conversion, one for main RGB scaling) versus vo_gpu's four (chroma merging, chroma scaling, RGB conversion, main scaling).

(Maybe it's offtopic, but I suddenly thought of it) gpu-next seems to avoid the issue #5727 in vo_gpu, which would make a little performance waste.

It does avoid that, yes.

[haasn]

Is this still an issue?

[aufkrawall]

Can't reproduce this one, so it's probably fixed.