Add Super-xBR and NNEDI3 for chroma prescaling

[Aktanusa]

I'm guessing currently Super-xBR and NNEDI3 are only being used on luma based on the option name prescale-luma, so I was wondering if it could be added for chorma too. With most material being in 4:2:0 colorspace, just scaling the chroma back to 4:4:4 would be perfectly 1 pass of the prescale.

[haasn]

You could make a copy of the super xbr code and run it using the user-shaders option. (Right now it would always run though, even on 4:4:4 content - but I plan on making that customizable)

I don't really want to introduce more of the prescaling nonsense into mpv, preferably move it out to user shaders wherever possible.

[Aktanusa]

Ah okay, thanks for the info!

[Aktanusa]

Just to make sure, would it be in the pre-shaders section or scale-shader?

[haasn]

would it be in the pre-shaders section or scale-shader?

Neither, I meant user-shaders.

[Aktanusa]

Oops, my bad. I'll take a look at that option, thanks!

[Aktanusa]

Ah I missed it because the PDF that came with the Windows build didn't list that option. I see it on the website.

On a off topic note (let me know if I should open another issue), I don't see anywhere where superxbr-sharpness or superxbr-edge-strength is explained, but by reading your code, I can figure out the range at least.

[bjin]

@Aktanusa I updated the nnedi3 user shaders to support chroma prescaling, see https://gist.github.com/bjin/4b1ab282412b94200dbe09de998348e6

[Aktanusa]

Thanks a lot! I'll take a look when I get back from work.

[paulguy]

Neato. although using nnedi3-nns32-win8x6.hook works perfectly fine, but the -chroma version of it becomes a slideshow. The video I'm playing is 720x480 yuv420p. I would think that even though it's doing it over 2 planes, it's still 1/4 of the pixels per plane, so it's still processing 1/2 the pixels overall. I don't know enough about how this shader works though to know if that's equivalent though.

[bjin]

@paulguy You are correct, chroma-only prescaling should be two times faster. And it's the case for nnedi3-nns32-win8x4.hook but not nnedi3-nns32-win8x6.hook, which is almost 7 times slower as I measured just now (with nvidia driver).

My guess is it's due to compiler optimization working poorly on nnedi3-nns32-win8x6-chroma.hook, need further investigation though.

EDIT: I checked all the combinations and it seems that nnedi3-nns32-win8x6-chroma.hook is the only one whose performance doesn't scale (nvidia driver). So please choose another setting for now.

[Aktanusa]

@bjin wow, looks great! Seems to do exactly what I want. Now to get off my lazy ass and compile a Windows build, or install Linux, though AMD drivers on Linux is iffy, lol.

Edit: Just curious, does the -yuv version perform better than -all on YUV sources hence why that option is there?

[bjin]

Just curious, does the -yuv version perform better than -all on YUV sources hence why that option is there?

They should be the same if you are playing YUV video only (and have a decent GLSL compiler to remove dead code). As for the reason providing a YUV only version, it's not recommended to apply luma prescaler to RGB video, since highly visible artifacts will be produced (much worse than chroma prescaling).

[Aktanusa]

Ah, thanks for your answer. Now excuse my ignorance, but I thought super-xBR was originally meant for pixel art, which I thought would be in RGB. I would think there wouldn't be artifacts with it, unless you mean the artifacts are with nnedi3?

[bjin]

I thought super-xBR was originally meant for pixel art, which I thought would be in RGB. I would think there wouldn't be artifacts with it, unless you mean the artifacts are with nnedi3?

Super-xBR was refactored to work on luma plane only when it was ported to mpv. The motivation behind this move at that time was that not to introduce prescaling on both luma and RGB (to avoid increasing maintain code of prescaling code). This isn't true anymore with @haasn's new hook system. It's now possible to add a version of Super-xBR that works properly on RGB (with either luma plane from source, or some random colormatrix). But until then, please don't use current "-all" version which literally applies luma prescaling on "R" and "G" and "B" separately.

[Aktanusa]

Thanks for the explanation and patience with me! Now I understand and won't use "-all" on RGB sources. It also explains why with the original code @haasn implemented didn't apply to RGB sources, since it didn't make sense.

[haasn]

Note that superxbr could also probably be refactored to scale R,G,B simultaneously (using matrices instead of vectors).

I did manage to get a proof-of-concept of this working once, so if you really care about RGB scaling and performance you could try to apply it yourself.

[bjin]

@Aktanusa I made some changes to superxbr shader in order to bring the native RGB upscaling back. You could try it with https://github.com/bjin/mpv-prescalers/blob/master/superxbr-native.hook

[Aktanusa]

@bjin Thanks so much for all your work! I'll try it out when I can. Most of my RGB sources are from emulators so I only sometimes need it.

[ghost]

Left to user scripts.

[v-fox]

Previously I used
-vf=format=yuv422p (needed for motion-based interpolation)
-vo opengl-hq=interpolation:interpolation-threshold=-1:tscale=oversample:tscale-radius=2:tscale-clamp:prescale-luma=superxbr:prescale-passes=2:prescale-downscaling-threshold=1.35

[with and without -vf-add vapoursynth=~/.config/mpv/motioninterpolation_720p.vpy] in hopes that it would upscale video up to 360p to x4 and up to 720p to x2 on 1080p display. What would be closest settings for these "hooks" ?

[Aktanusa]

@bjin I finally got time this weekend to test these out. It works great! Thanks again. I should note the only problem I had was loading multiple hooks, which @haasn helped me by telling me the files should be like so:

user-shaders="[<first hook>,<second hook>,...]"

@v-fox remove:

prescale-luma=superxbr:prescale-passes=2:prescale-downscaling-threshold=1.35

and add:

user-shaders="[<path to hooks>/superxbr.hook,<path to hooks>/superxbr.hook]"

This will emulate what the original command was doing, which is only prescaling on the luma channel. If you want to prescale on the chroma also, you need to use a different hook. @bjin 's README should explain which does what.

[v-fox]

files should be like so:

user-shaders="[,,...]"

It seems that using multiple hooks is really finicky and mpv fails Error parsing option vo (option could not be parsed) if it doesn't like something without telling what it is. Neither user-shaders="[<first hook>,<second hook>,...]" or user-shaders="<first hook>,<second hook>,..." from the README work for me. I had to use user-shaders=\"<first hook>,<second hook>,...\". That's right, escaping " and it doesn't work completely without " either.

This will emulate what the original command was doing, which is only prescaling on the luma channel. If you want to prescale on the chroma also, you need to use a different hook. @bjin 's README should explain which does what.

I've read it but there is nothing about over-upscaling and how to avoid it and I'm not sure which hook I should use for superxbr upscaling in most situations if I'm also using vf=format=yuv422p.
As of now, it may artifact on some videos if format filter is used and there isn't any over-upscaling limiting which just hangs mpv on high-res videos which makes it pretty much unusable in general usage scenario.

[bjin]

I had to use user-shaders=",,...". That's right, escaping " and it doesn't work completely without " either.

The escaping is required by the shell you are using (like bash) and has nothing to do with mpv. Write configure files and use profiles to switch vo settings instead.

I've read it but there is nothing about over-upscaling

This is limited by the current condition support (WHEN statement) in user shaders, which applies to all passes individually. So if upscaling is not required, only the first pass will be ignored, but not the second pass.

I know a few dirty tricks to ignore both passes, but I don't like the approach and thus it's not implemented.

I'm not sure which hook I should use for superxbr

If in doubt, use superxbr-native.

As of now, it may artifact on some videos if format filter is used

This is not expected. What kind of artifacts did you see?

[v-fox]

The escaping is required by the shell you are using (like bash) and has nothing to do with mpv. Write configure files and use profiles to switch vo settings instead.

Yep, like 99% of all user terminals (although I use zsh). And since mpv doesn't have official GUI, users of things such smplayer and Xt7 will have to figure out that they have to 1) have " in their in-GUI configs 2) then escape them. Probability of anyone doing it is close to zero. That's why " was a poor choice for a required character of command line option.

I know a few dirty tricks to ignore both passes, but I don't like the approaches and thus it's not implemented.

I'm not sure what logic is now but it would be absolutely insane to hardcode power-of-two upscaling everywhere. Current code simple isn't any replacement for the old one until it starts calculating sane target upscale ratio itself and single hook would become enough for that.

If in doubt, use superxbr-native.

Does indeed seems to work without artifacts. Dropping frames like crazy on HD thought. And this kind of strong upscale algorithms are only really needed for low-res muddy videos to get all details out of them.

This is not expected. What kind of artifacts did you see?

Strangely I can't reproduce it anymore at all >_< But first time I tried with format filter and pretty much any superxbr hook, whole video where overlayed with purple and green "net" of dots and small lines.

[Aktanusa]

It seems that using multiple hooks is really finicky and mpv fails...

I'm on vanilla Ubuntu (don't judge me >_<) which I think uses bash as the default shell and I didn't have any problems using "[...]". Weird.

I'm not sure what logic is now but it would be absolutely insane to hardcode power-of-two upscaling everywhere. Current code simple isn't any replacement for the old one until it starts calculating sane target upscale ratio itself and single hook would become enough for that.

I agree right now it seems a bit complicated to auto set the user hooks depending on the file, but looking through the manual, I think it might be possible with LUA scripting and command interface (though the vo-cmdline input command might go away).

[Aktanusa]

@bjin I just noticed in the README that it mentions for YUV4:2:0 that the luma and chroma planes are not aligned if using a hook for chroma, and then use a hook for all YUV. Can you elaborate on what you mean by not aligned?

[bjin]

cscale will always be required in almost all cases.

For example, you get a YUV 4:2:0 video of size 1280x720. The chroma plane is 640x360. After applying superxbr-chroma.hook, it becomes 1280x720, the same as luma plane. But you can't merge luma and chroma planes directly even though they have the same size, since they are not aligned. It's due to how superxbr upscaling works, and possibly also due to MPEG-2 chroma sampling location not at the center.

[Aktanusa]

Thanks for the explanation. That's what you meant. I knew that the chroma placement is different between MPEG1 and MPEG2, but I didn't understand you were warning that the pixel shift would be done with cscale, which makes sense since all these hooks can only 2x a plane.