Weird color bleeding

[brian6932]

No shaders set glsl-shaders ~~/shaders/KrigBilateral.glsl set glsl-shaders ~~/shaders/CfL_Prediction.glsl set glsl-shaders ~~/shaders/CfL_Prediction_Lite.glsl Actual badge

1. 
2. 
3. 

   ---

   To repro

   mpv --no-config --gpu-api=vulkan --gpu-context=winvk --glsl-shaders=CfL_Prediction.glsl --pause --mute --fs --start=00:01 305680773-dfaed0b1-79d0-44f0-b53d-52b3e6df5988.mp4

https://github.com/Artoriuz/glsl-chroma-from-luma-prediction/assets/18603393/dfaed0b1-79d0-44f0-b53d-52b3e6df5988<-file

[Jules-A]

I can't reproduce that but that's just with opening that tiny "no shaders" image you posted. It's also possible it can't reproduced with such a tiny single png that is likely not even from source or is being scaled by whatever your default MPV settings are. You'll need to provide the settings you're using in MPV also.

[brian6932]

So for some reason when using libplacebo with ffmpeg, and applying the shader directly, this behavior doesn't happen, but in mpv when it's applied to the video it occurs.

Yes it's apart of a larger video, and the screenshots were taken from within mpv, then cropped. I'm not against providing an image, but I want to be able to test it first hand on the image. The problem is, when I launch an image with mpv, and scale, shaders don't apply, even if the image is within an mp4 container. Not sure how that works, am I missing some init_hw_device-like flag? Does it take too long to load the shader? Or is this some bug?

[mightyhuhn]

of course you can't reproduce that on the no shader according to the to me dead link it is an png so no Chroma to scale.

here is another extreme example of prediction failing massively: https://i.slow.pics/SRXDnZ9i.png it from this comparison: https://slow.pics/c/fm2rliLr it produces a lot of noise around well everything and is just generally adding artifacts everywhere. 5 and 6 show that very clearly.

https://drive.google.com/file/d/1E7-XBHJ6Jlndafm5URsxCU3z-oAmZolW/view only chroma was scaled and dithering was active GPU-next was used.

if you are fine with the usually issues of biliteral https://github.com/Artoriuz/glsl-joint-bilateral performs more save.

[Jules-A]

of course you can't reproduce that on the no shader according to the to me dead link it is an png so no Chroma to scale.

You can scale luma above output but obviously it's not great for testing but not much else to do with so little available.

here is another extreme example of prediction failing massively: https://i.slow.pics/SRXDnZ9i.png it from this comparison: https://slow.pics/c/fm2rliLr it produces a lot of noise around well everything and is just generally adding artifacts everywhere. 5 and 6 show that very clearly.

CFL seems to have quite a few issues with discolouring (mostly reds) and removing outlines (I created an issue for it ages ago here: https://github.com/Artoriuz/glsl-chroma-from-luma-prediction/issues/5 ). It is slightly better with the last change in master but still far from optimal so I've been trying to fix it myself. I've come up with this: https://pastebin.com/raw/Esn9P1KS , if you could test that and tell me how it goes for you (vs master) it would be helpful. EDIT: It's also using some code from deus0ww for speed.

[mightyhuhn]

looks pretty much the same as ravu-r2 massive ringing and some aliasing it kind of looses to the bad super xbr implantation. i don't see a reason yet to use it over joint.

i can't benchmark chroma scaler i get around 1200-1800 fps which falls down to around 600 from showing the OSD... and the GPU is at best at 60 % load if the OSD cost more then the entire rendering pipeline i'm not benchmarking. i can do decent test with image scaling from FHD to UHD which does not apply here.

[Jules-A]

looks pretty much the same as ravu-r2 massive ringing and some aliasing it kind of looses to the bad super xbr implantation. i don't see a reason yet to use it over joint.

Could you give an example of the ringing and what are you comparing it to? It should be much better than CFL master, at least in my video I use for testing which is my most ringy example I have it's almost enough to eliminate it all. You could always try editing the AR, say increasing it from 0.83 to 0.95.

Also, are you testing with any other shaders or just on it's own?

Aliasing is understandable at high scaling factors like 720->4k but I don't think it should be that high with 1080->4k? I mainly tested 720-1080p -> 1440p or scaling it to 4k but then it gets downscaled which likely removes some artifacts (especially aliasing).

[mightyhuhn]

the gold standard for me is super xbr 100 i usual use 150 in comparisons to make a point.

edit: i messed the images up again huhn english for chicken has an marble sized brain. the following stuff is to be ignored.

one of them is ravu r2 another one is your new version which pretty much looks the same as ravu if you ask me and one of them is super xbr not the normal one it was ported from a pretty bad two path version.

i'm not very confident in my mpv usage. when i usually do chroma it is native only chroma or the scaler after chroma is the same for all images.

[Jules-A]

one of them is ravu r2 another one is your new version which pretty much looks the same as ravu if you ask me and one of them is super xbr not the normal one it was ported from a pretty bad two path version.

??? That's not very helpful... Is it possible you got the images mixed up? Also if you are comparing with Super XBR, the MPV shaders I found look to be scaling LUMA as well so it's not really a fair comparison since CHROMA would likely be at 2x the resolution vs pure chroma scalers so aliasing would be less noticible. EDIT: I found the CHROMA only version but no idea if you are using that. It looks pretty terrible and kills tonnes of detail in pretty much everything but the Junji Ito sample that murders CFL (and I'm still trying to get it working better). Honestly you're probably better off using Catmull_rom + Pixel-Clipper for AR or the new Ravu-R3-AR reporposed as a Chroma shader: http://github.com/deus0ww/mpv-conf/blob/master/shaders/ravu/zoom/ravu-zoom-ar-r3-chroma.hook if you need something that can handle the extreme samples better.

[mightyhuhn]

as usually i messed up i pressed control+s before control+v and it will use an empty shader just fine no error in the console or anywhere.

real test: https://slow.pics/c/HE2JXUyl luckily it really rings even through i never saw it before. the major errors have been ignored in my judgement.

new predition decent chroma placement but ringing also shows issues with aliasing. ravu r2 rings everywhere... ravu r3 slightly better lines ringings everywhere super xbr soft trash but low errors also soft rigning.

ohh you call that an extreme sample? i have far worse ones but this is very very real one.

the mpv super xbr version is trash but it still does better here in this one image at least in terms of ringing... but this version is soft very very soft. this here is not a super xbr issue i could whine about this for years here are 4 other super xbr test i did. most of them use the real super xbr as it should be: https://slow.pics/c/KbViAj68 https://slow.pics/c/72JEh0DC https://slow.pics/c/ejSmXG85 https://slow.pics/c/QJOn0psT

i don't want to turn this into an super xbr talk that's also one reason i didn't use the good super xbr: the scaler i used have been taken from here: https://github.com/bjin/mpv-prescalers/tree/1fb1c079405b674d54206ff2c52fd520db63ff10 and here: https://github.com/bjin/mpv-prescalers/tree/cc02ed95c1fe05b72bc21d41257c4c085e6e409b

here some more test images and stuff: https://drive.google.com/file/d/1X6tIcONvEGHLBoCM_-mOn0syTuLweCW0/view?usp=sharing it just a zip with all stuff i did in the other test the 420 folder should be useful to you the abbration is used to show that bilateral scaler place Chroma wrong from time to time not to show the benefit of chroma scaler.

good chance i messed something up again.

[Jules-A]

I can't reproduce those random square artifacts or that insane colour bleeding in the other CFL screenshot. Have you tried making sure no other shaders are running? Maybe it's some other setting messing something up? Try running something like this: mpv --no-config --vo=gpu-next --pause --save-position-on-quit --glsl-shader="C:\Users\Jules\AppData\Roaming\mpv\shaders\Cfl_test9.glsl" "E:\Videos\Crunchyroll\Yu-Gi-Oh! ZEXAL - S3E131 - Power Play.mkv" pause in a .bat file in mpv directory. It may be that gpu-next is needed (I never tested vo=gpu) though it could also be a driver bug (I think I recall Intel needed linearizing for some reason but that requires GPU-next)?

the scaler i used have been taken from here:

doesn't really help because you didn't specify if you used the chroma specific one or not.

ohh you call that an extreme sample? i have far worse ones

I tried the ones in your example, they weren't really tough at all, nothing in comparison to that Junji Ito sample.

also shows issues with aliasing

The source image has heaps of aliasing but again, I don't see anywhere near as much with my shader, this is what I see:

You seem to have way more issues than the shaders though, your colors look completely off to me, way too bright.

ringing

I watch almost entirely official sources so I just adjusted to my worst sample. Your test image has a decent amount and I do still see it, however it's not as noticible. I just realised that the way AR is set up in this shader it REQUIRES gpu-next since it's using a new gpu-next feature, really not sure what happens on vo-gpu, maybe it just sets it to 0? If you need higher you can just increase this value in something like notepad: It can also be set in config files with gpu-next and possibly even changed at runtime but not sure. here's it with 0.98 AR and linearization (requires gpu-next): https://pastebin.com/raw/CC956X6a

Maybe OP should also check if they are running gpu-next.

[brian6932]

Maybe OP should also check if they are running gpu-next.

I use gpu-next

[mightyhuhn]

I can't reproduce those random square artifacts or that insane colour bleeding in the other CFL screenshot. Have you tried making sure no other shaders are running? Maybe it's some other setting messing something up? Try running something like this: mpv --no-config --vo=gpu-next --pause --save-position-on-quit --glsl-shader="C:\Users\Jules\AppData\Roaming\mpv\shaders\Cfl_test9.glsl" "E:\Videos\Crunchyroll\Yu-Gi-Oh! ZEXAL - S3E131 - Power Play.mkv" pause in a .bat file in mpv directory. It may be that gpu-next is needed (I never tested vo=gpu) though it could also be a driver bug (I think I recall Intel needed linearizing for some reason but that requires GPU-next)?

are you on AMD? all shaders are called this way

CTRL+1 change-list glsl-shaders set "~~/shaders/new-predict.glsl";
CTRL+2 change-list glsl-shaders set "~~/shaders/ravu-zoom-r2-chroma.hook";
CTRL+3 change-list glsl-shaders set "~~/shaders/ravu-zoom-r3-chroma.hook";
CTRL+4 change-list glsl-shaders set "~~/shaders/superxbr-chroma.hook";
CTRL+5 change-list glsl-shaders set "~~/shaders/CFL_predition.glsl";
CTRL+6 change-list glsl-shaders set "~~/shaders/jointbiliteral.glsl";

i don't have appended in my config or input as far as i know i'm not able to run 2 shaders at the same time.

my config is pretty much blank of cause i'm doing image comparison here deband=no. but else there is some screentshoot stuff in there and gpu-api=vulkan fbo-format=rgb32f

edit: error comes from gpu-api=vulkan

doesn't really help because you didn't specify if you used the chroma specific one or not.

i was told mpv is always doing chroma to luma resolution first. so either it is not used at all or it is a chroma one. these are all chroma ones. else it wouldn't do anything if that information was correct. and i tried loading a image scaler when i was doing only Chroma it was not loaded AFAIK.

I tried the ones in your example, they weren't really tough at all, nothing in comparison to that Junji Ito sample.

the what? The source image has heaps of aliasing but again, I don't see anywhere near as much with my shader, this is what I see:

a scaler should remove aliasing nearly every scaler does. does mpv add an empty icc profile to screenshoots? and are you on linux and it actually cares not like my windows? You seem to have way more issues than the shaders though, your colors look completely off to me, way too bright.

if you ignore the errors as i have the colors are exactly the same.

I watch almost entirely official sources so I just adjusted to my worst sample. Your test image has a decent amount and I do still see it, however it's not as noticible. I just realised that the way AR is set up in this shader it REQUIRES gpu-next since it's using a new gpu-next feature, really not sure what happens on vo-gpu, maybe it just sets it to 0? If you need higher you can just increase this value in something like notepad: It can also be set in config files with gpu-next and possibly even changed at runtime but not sure. here's it with 0.98 AR and linearization (requires gpu-next): https://pastebin.com/raw/CC956X6a

Maybe OP should also check if they are running gpu-next.

i have another input.conf which was not used here:

CTRL+5 change-list glsl-shader-opts set "ar_strength=1";
CTRL+6 change-list glsl-shader-opts set "ar_strength=0";

this works with this newer NN scaler

[Artoriuz]

@brian6932 Since it was impossible to reproduce with what you provided directly, I made myself a test clip: https://github.com/Artoriuz/glsl-chroma-from-luma-prediction/assets/12078193/d2ceca25-3f47-4dcc-8d2c-9f80a73c016c

This is the output without any shaders:

And this is the output with CfL:

Everything is working as expected, so I don't know what you did.

Assuming your actual video was a bit noisy, it's possible that the noise would occasionally put the backgroung closer to the red portion in luma intensity, which would explain why CfL would produce such "bleeding".

There's nothing I can do about noise other than literally denoising the luma plane before using it, but doing that would hurt shader's capability of generating fine-detail.

[Jules-A]

are you on AMD? stuff in there and gpu-api=vulkan fbo-format=rgb32f edit: error comes from gpu-api=vulkan

Yeah, I'm using an AMD 6700XT with DX11 on Win10 since it's been better than Vulkan pretty much always.

as far as i know i'm not able to run 2 shaders at the same time.

You can apply multiple shaders by separating with ; CTRL+8 no-osd change-list glsl-shaders set "~~/shaders/ravu-zoom-ar-r3.hook;~~/shaders/cfl_test.glsl";

i was told mpv is always doing chroma to luma resolution first. so either it is not used at all or it is a chroma one. these are all chroma ones. else it wouldn't do anything if that information was correct.

The ones that hook at native or main will be after chroma has been upscampled to luma with the inbuilt chroma scaler (need to hook chroma to scale just chroma) and end up scaling both luma and chroma. That's why I was emphasizing the importance of it being just chroma scaling for comparison.

the what?

https://github.com/Artoriuz/glsl-chroma-from-luma-prediction/commit/3fc1c1a73c86e537a339ec3623e22c48d8438879#commitcomment-138326390

CFL and my attempts to improve the downscaler seem to fail miserably on that sample since it seems to be removing a lot of the shadowing, softer scalers do a lot better here but it's rare to see anything close to that sample in content.

a scaler should remove aliasing nearly every scaler does.

Sure and if you check my screenshot, a lot is being removed but CFL derives Chroma from Luma, it's not supposed to change the whole image, that's more the Luma scaler's job. Ravu is pretty good at removing aliasing at the cost of thinning lines, however if you are on a slower system using both Ravu and CFL might be a bit too costly. If you want to remove even more aliasing you can overscale (idk the correct term) but scaling above output resolution so MPV does downscaling, however depending on the downscaler, a lot of detail can get lost in the process).

[mightyhuhn]

that's super sampling. chroma is already x2 from just matching the luma after that the scaler doesn't matter much anymore. what so ever ravu performance is subpar in my opinion and if you want to talk about this topic here: chroma red 720 (1).mkv and chroma red 720 (2).mkv show similar issues with the original shader.

BTW. just using vo=GPU will give you wrong images in form of sRGB correction from gamma or with other words by default is is not leaving the image untouched but does changes the tone curve.

[Jules-A]

that's super sampling. chroma is already x2 from just matching the luma after that the scaler doesn't matter much anymore.

No it's not. The chroma will match luma with the inbuilt scaler and the shaders that hood native/main will scale the combined planes.

chroma red 720 (1).mkv and chroma red 720 (2).mkv show similar issues with the original shader.

Yes, it's tough for the original CFL but I spent a lot of time changing the downscaler specifically so it could handle reds/match source better and those samples aren't enough to cause any major issues with it but the Junji Ito sample completely trips it up (though it is better than my earlier attempts).

[mightyhuhn]

No it's not. The chroma will match luma with the inbuilt scaler and the shaders that hood native/main will scale the combined planes.

my point was that it does not matter for chroma not that you can't do that. or to say it differently you can upscale 540p to 2160 using FSRCNNX twice that doesn't mean it will make much or any difference to FSRCNNX to 1080p rest bicubic 60.

[Jules-A]

@mightyhuhn I think what you are looking for is https://raw.githubusercontent.com/Jules-A/glsl-chroma-from-luma-prediction/main/CfLP_Ravu (it's deus0ww's CFLxRavu combination replaced with my DS variant). Removes a tonne of aliasing for just a chroma scaler although it's 2-3x slower to run than CFL master. I also brought back the jinc window in my DS code: https://raw.githubusercontent.com/Jules-A/glsl-chroma-from-luma-prediction/main/CfLP_NewDS which smooths out small aliasing (mainly the furriness of using a hermite base) a bit and reduces blocking a little bit at the cost of some speed.

Test images

CFLxRavu:  SuperXBR:  CFL(my variant):  CFLxRavu (with mix_coeff=0.5): 

[mightyhuhn]

i actually wanted to stay on topic because i saw similar issues with the scaler.

i'm willing to talk about any type of chroma scaling here: https://github.com/haasn/libplacebo/issues/241#issuecomment-1913397974

i can not keep thsi to me but your super xbr is horrible. all your scaler are not chroma bleeding anymore.

[Jules-A]

i actually wanted to stay on topic because i saw similar issues with the scaler. i can not keep thsi to me but your super xbr is horrible. all your scaler are not chroma bleeding anymore.

I kind of feel that's worse since this issue is at least closed and they aren't going to re-add complex shaders to inbuilt options. The version of super xbr is purely Chroma scaling, not also Luma like the others you said you were using, you can't use them for comparisons of chroma.

The colour bleeding may be a graphics driver issue or possibly the result of wrong MPV settings, however the OP didn't provide a source, didn't provide a log, didn't try running with no config so the issue is completely invalid anyway. You were using wrong MPV settings, as I noticed in another MPV issue so I doubt the issue is with the shaders at all, likely not even drivers.

EDIT:

This is what scaling all with SuperXBR and Ravu zoom3ar luma+that ravu hybrid compares

SuperXBR:

RAVU:

[mightyhuhn]

no the problem with super xbr that the port is not well the super xbr that is actually usable. i can only guess if it is 2 pass fast version or something. and i'm using it correctly: CTRL+4 change-list glsl-shaders set "~~/shaders/superxbr-chroma.hook" your "all" looks the same as your chroma image as it should be.

this is how super xbr should look like: https://i.slow.pics/ba54ofsp.png

or take this one an image where it actual does good: https://slow.pics/c/QJOn0psT

or take this example: https://slow.pics/c/KbViAj68 i even made mpdn work again where super xbr is ported from. source was png mpdn doesn't have a chroma version. they are not the same. and no i can not load a GLSL by accident wrong that moves teh image around that's a bit hard to pull off.

[brian6932]

OP didn't provide a source, didn't provide a log, didn't try running with no config so the issue is completely invalid anyway.

Ok first of all, I did produce it on no-config, not that this is relevant at all, I'm using the shader as a control. Not sure wtf kind of logs you want. Second, I asked a question and no one responded.

The problem is, when I launch an image with mpv, and scale, shaders don't apply, even if the image is within an mp4 container. Not sure how that works, am I missing some init_hw_device-like flag? Does it take too long to load the shader? Or is this some bug?

I'm not uploading the whole video.

[Jules-A]

Ok first of all, I did produce it on no-config, not that this is relevant at all, I'm using the shader as a control. Not sure wtf kind of logs you want. Second, I asked a question and no one responded.

Ah yeah, sorry, I guess it's not asked for anywhere but it's kind of impossible to reproduce the issue with no info at all. The logs are an easy way to get what settings used or if there were any errors (can be created by adding --log-file="D:\ExampleLogs\mpv.log" ect.) but honestly just knowing all settings used (copy of mpv.conf if there's a lot of changed stuff ect.) would be extremely helpful. As for source, a full screenshot or at least a larger crop would be way better than that icon you posted :/ though if it's something that occurs over multiple frames then something like losslescut to cut a few seconds would help more. EDIT: The log will also tell what hardware/OS you are running on which is extremely important...

The problem is, when I launch an image with mpv, and scale, shaders don't apply, even if the image is within an mp4 container. Not sure how that works, am I missing some init_hw_device-like flag? Does it take too long to load the shader? Or is this some bug?

Sorry, I missed that but most scalers have conditions to meet in order to scale, if you want to make sure it always activates you can simply delete the //!WHEN lines but they are generally there since scaling at resolutions that don't meet the clause can wasteful, detrimental or possibly not even work at all. If you can wrap your head around Reverse Polish Notation you could edit it to make the conditions more forgiving.

[mightyhuhn]

a jpg instead of an png is able to capture the screenshot at 4:2:0. avif should also do that. this should provide a sample that give us reproduceable results.

[Jules-A]

a jpg instead of an png is able to capture the screenshot at 4:2:0. avif should also do that. this should provide a sample that give us reproduceable results.

Hell NO! NOT jpg or any other lossy formats... They destroy a tonne of detail that can never be recovered, while a lossless image can be encoded to anything that's needed.

[mightyhuhn]

please don't do that to me. this is not an image comparison where lossless is needed.

yes i could go and teach him mkvtoolnix yes i could even teach doing a lossless encode of the frame in question like i do for chroma comparison and where it is kind of needed. the png screenshot has the issue of been RGB making chroma test impossible and not lossless for what we are doing here the avif or jpg screens can be 420 and according to the https://mpv.io/manual/master/ it will use the source colorspace meaning we get a lossy compression of the same frame and it is very easy to do.

after we got that we can use that as a new groundtruth to see if the problem can be reproduced. if it works Artoriuz get's something to work with.

[kasper93]

@brian6932: I've not read whole thread, but I believe it is unrelated to your issue anyway. Let's focus on what you said.

So for some reason when using libplacebo with ffmpeg, and applying the shader directly, this behavior doesn't happen, but in mpv when it's applied to the video it occurs.

This is interesting observation. In theory it shouldn't happen, but in the same there might be many reasons why the output is different, so for us to diagnose we have to have some sample input that we can debug.

(If I had to give you one guess, in ffmpeg the shader didn't actually apply, because of some unexpected conversion before)

Yes it's apart of a larger video, and the screenshots were taken from within mpv, then cropped. I'm not against providing an image, but I want to be able to test it first hand on the image. The problem is, when I launch an image with mpv, and scale, shaders don't apply, even if the image is within an mp4 container.

This is kind of expected depending how you made a image. You probably should just copy stream without any changes to make it work the same, command like the following will help

ffmpeg -i <file> -frames:v 1 -c copy a.mkv

probably need -ss to seek to certain point in video. And you can change -frames:v for -t to make short clip instead one frame.

Not sure how that works, am I missing some init_hw_device-like flag? Does it take too long to load the shader? Or is this some bug?

Hard to say really. Best if you can provide easy steps to reproduce the issue, so we can debug on our side.

[Artoriuz]

@brian6932

The problem is, when I launch an image with mpv, and scale, shaders don't apply, even if the image is within an mp4 container.

I had missed this due to all the noise, but keep in mind some shaders require specific pixel formats which means they might not trigger on RGB.

[mightyhuhn]

ffmpeg -i <file> -frames:v 1 -c copy a.mkv

probably need -ss to seek to certain point in video. And you can change -frames:v for -t to make short clip instead one frame.

that's how i do it -s:v 1920x1080 -r 24 -c:v libx264 -crf 0

[Jules-A]

that's how i do it -s:v 1920x1080 -r 24 -c:v libx264 -crf 0

That's completely different, you are re-encoding the video which entirely changes the image. The suggestion is to losslessly copy only a single frame or timeframe. If you want to do timeframes it's much easier with a program like LosslessCut imo, especially for people not too familiar with ffmpeg.

[brian6932]

Ok, did a little testing, it's faint without gpu-api=vulkan, but when gpu-api=vulkan (on Windows, so gpu-context=winvk), it becomes more apparent. Doesn't matter if I'm using vo=gpu-next or vo=gpu, nor hwdec=nvdec-copy and hwdec=no. Well with lossless clipping, you have to use keyframes, so the vid's a few frames longer, but whatever, re-encoding is out of the question here. I originally clipped a portion with streamsave, when testing initially, but it was pretty large, so I reduced it to the last keyframe.

mpv --no-config --gpu-api=vulkan --gpu-context=winvk --glsl-shaders=CfL_Prediction.glsl --pause --mute --fs --start=00:01 305680773-dfaed0b1-79d0-44f0-b53d-52b3e6df5988.mp4

https://github.com/Artoriuz/glsl-chroma-from-luma-prediction/assets/18603393/dfaed0b1-79d0-44f0-b53d-52b3e6df5988<-file

I will update my (Nvidia) GPU drivers, after making this, and test one more time, but I'm doubtful if any winvk updates help with this. Doesn't help, updated to the latest studio driver

❯ nvidia-smi
Sat Feb 17 21:33:05 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 551.23                 Driver Version: 551.23         CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------+

❯ mpv --version
mpv v0.37.0-337-gbd5b80ba Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Feb 18 2024 00:09:08
libplacebo version: v6.338.0-77-g3ba18d5-dirty
FFmpeg version: N-113670-g0895ef0d6
FFmpeg library versions:
   libavutil       58.39.100
   libavcodec      60.39.101
   libavformat     60.21.100
   libswscale      7.6.100
   libavfilter     9.17.100
   libswresample   4.13.100

[mightyhuhn]

vulkan has been used d3d11 performs better:

that's how i do it -s:v 1920x1080 -r 24 -c:v libx264 -crf 0

That's completely different, you are re-encoding the video which entirely changes the image. The suggestion is to losslessly copy only a single frame or timeframe. If you want to do timeframes it's much easier with a program like LosslessCut imo, especially for people not too familiar with ffmpeg.

no it does not change a single bit in the output frame. it's CRF=0 it's 4:4:4 predictive lossless the 4:4:4 is not the sub sampling. if you want to make sure it's always the same frame here you go. yes i was to lazy to add the meta data because it really doesn't matter here. newtest1.zip

[Jules-A]

Ok, did a little testing, it's faint without gpu-api=vulkan, but when gpu-api=vulkan (on Windows, so gpu-context=winvk), it becomes more apparent.

Test with default settings (with GPU-Next I think since I think that's the expected vo considering the AR setup), if it's worse with Vulkan then it's probably way more likely to be a driver/MPV bug rather than the shader itself and maybe worth reporting as an MPV issue.

EDIT: I am able to reproduce the issue even with default settings:

Though nowhere to the effect you guys are...

And it does not occur with my version of the shader which is mostly a replacement of the downscaler and editing a few values so I'd say it's a legitament issue (Vulkan doesn't make it any more noticeable for me).

Obviously I can't confirm if that is originally in the source recording and the other chroma upsamplers are removing it but either way I feel like it probably should be removing it even if that was the case.

EDIT2: Lol that clip actually does show a more obvious colour bleed:

which also doesn't occur with my version of the shader (or default cscale):

Though mine bleeds greens rather than reds.

[brian6932]

This is still occurring on b7920358a84dac291c2042f0ccaa289fd333279a

[Jules-A]

This is still occurring on b792035

Try this: https://github.com/Artoriuz/glsl-chroma-from-luma-prediction/blob/a759bf95e55ad4846c0948750e8d35d9a8a657a5/CfL_Prediction_Dev.glsl

Looks like Artoriuz is looking into fixing it. While that experiment has been removed as it has it's own issues, it did actually fix quite a few issues with clipping/thinning and maybe also colour bleeding. If it's too much of a downgrade visually I guess you could try mixing it at 50% so it's not as impactful. (I think output_pix.xy = clamp(mix(ct / wt, CHROMA_CFL_tex(CHROMA_CFL_pos).xy, 0.5), 0.0, 1.0); on the 3rd last line.

[brian6932]

Try this: https://github.com/Artoriuz/glsl-chroma-from-luma-prediction/blob/a759bf95e55ad4846c0948750e8d35d9a8a657a5/CfL_Prediction_Dev.glsl

Yea, it looks fixed here.