Madvr 4 Life (Help and Tips)

[tp4tissue]

Madvr is the only thing holding Tp4 back from full time linux. :devil:


It still just works gooder than any other playback tool.

Using lanczos still, power efficient, looks good.

Madvr also fixes banding on even the WORST monitors/tvs. No other software can do this.

[Columbo]

Maybe you could tell us what Tp4 is?

[hajj_3]

Maybe you could tell us what Tp4 is?

his username.

[Columbo]

Tp4 != tp4tissue

[Z2697]

I like MPV more now.
I used to like madVR more when comparing the two.
But now MPV has gotten better while madVR just stagnate...

[huhn]

i just wonder if mpv can do a greyscale correctly now. on the other hand not enough for me to test that yet again...
really dark dark times for video rendering

[Z2697]

i just wonder if mpv can do a greyscale correctly now. on the other hand not enough for me to test that yet again...
really dark dark times for video rendering

What is "doing greyscale", exactly?

[huhn]

taking a grey scale patch and getting grey back?

we talking about accurate rendering the basics of basics. libplacebo fails at it or was failing at it.
you can literally take a grey scale image and not get RGB in the same levels back. test like that.

or dithering set it to one bit maybe you notice at pattern. the job of dithering is spreading the error not taking a pixel and declaring it has a dumping pixel.
the whole blending was and most likely is still broken.
this quite a huge number of build in scaler with a literal broken kernel.

this thread is not about mpv. i can also list stuff that is broken with madVR. we both know that's not going to be fixed:-)

[pirlouy]

Just to be sure, did you report all those problems on libplacebo tracker ?
I think I saw you report for "Jinc" but I don't know about these greyscale issues.
I know that mpv tracker is full of issues and they tend to close as much as they can, even if some issues are still present, but with libplacebo, maybe there are more chances to be looked at ?

[huhn]

the greyscale is on libplacebo indirectly confirmed where it is directly confirmed that the image changes in a way it shouldn't. this is something a video render should never ever do.
the error was BTW. over 2 with itp measured with a meter. if you have a calibrated device and use mpv you have now uncalibrated it.

that was with ffmpeg not mpv. it was close without been fixed by the person opening it. nothing was found except that the output is wrong.

i had a direct report about this. i supposedly didn't do it correct and ask why i do wrong int he report now answer.

but yes i never saw haasn ever ignoring an issue but that doesn't mean i will try to report them. i do not have the skills for that. i can easily find issue but when it goes down to the really deep part i have no clue why they actually happen.

mpv and libplacebo have a massive issue where features are added left and right but barely any are actually finished completely.

then there is naming..
we have for transfer function

gamma, trc and transfer to be honest maybe more. yes PQ is sometimes a gamma. and that's ok if it would be consistent.

then bt 1886 was added something madVR can not do and it was hard coded to 1000 CR back in the day making it pointless.
but you can take it off a list...

after testing 1 bit dithering i gave up. i tried all algorithm i could find and all just use a dumpster pixel breaking the point of dithering in the first place.

then there was a feature with getting 420 to the screen function. which was just handsdown fake it's upscaled and then downscaled again. why is such a niche thing added. don't get me wrong i do not need this function i would have used it for ease of use but that's it i don't need it and i think 99.99% user don't need it.

[Sunspark]

huhn, out of curiosity did you ever test or compare vlc? I don't mean the stock settings, but changing the output mode to opengl and going to advanced settings video output modules opengl where you can choose between colour spaces, dithering, TRCs, etc. It has BT.1886 as an option in there.

[huhn]

no. but i guess there is a reason libplacebo was removed from vlc i do not know if that is still the case.

and bt 1886 as an option make barely any sense anyway.
to use bt 1886 you need to tone map or for what ever reason don't want bt 1886 on a bt 1886 calibrated device.

barely anyone calibrated to bt 1886 on a static but none perfect CR display. most devices are perfect black that are calibrated or are not calibrated to bt 1886 or can not be calibrated to bt 1886 cause they do not have a stable black floor like all PJ.
most devices also do not have a powerful CMS to do bt.1886.
where bt 1886 is used in 3D LUT calibration but that doesn't make the trc of the device bt 1886 the 3D LUT makes it bt 1886 big difference.

SDR calibration is usually 2.4 relative and most of the time absolute 2.4. it does not matter that they grand fathered bt 1886 in.

[tp4tissue]

huhn, out of curiosity did you ever test or compare vlc? I don't mean the stock settings, but changing the output mode to opengl and going to advanced settings video output modules opengl where you can choose between colour spaces, dithering, TRCs, etc. It has BT.1886 as an option in there.


This is 1 other area where madvr is irreplaceable. :eek:

The tone patch generator has integration with HCFR and Displaycal.


No other system can you "TEST" End-to-End. VideoFile to Photon


It doesn't matter what MPV or VLC does, if they don't have integration, we have NO IDEA what we're getting out on the other end.

They could have bugged gamma, or mysterious clipping, or gamut error. You simply can't know.


This is no small issue, the madvr tone patch generator even has APL compensation which is important to spot weird ABL behaviors on modern screen technologies in oled and lcd local dimming.

[pirlouy]

Ahah huhn, I have no idea what you're talking about, but with all this passion, it would be a shame if you didn't try to report your issues in the tracker. Maybe devs are just not aware and just need your samples/examples.
But I could understand you don't want to enter a fight with someone who is not interested and just want to close the ticket quickly.

And I didn't know VLC was not using libplacebo anymore !

[huhn]

my information is dated and not freshly verified libplacebo is maybe part of vlc again but it was removed and they may have fixed many of these bugs i just want to make that clear.

cause i can look it up fast: "--target-contrast=<auto|10-1000000|inf>
Specifies the measured contrast of the output display. --target-contrast in conjunction with --target-peak value is used to calculate display black point. Used in black point compensation during HDR tone-mapping. auto is the default and assumes 1000:1 contrast as a typical SDR display would have or an infinite contrast when HDR --target-trc is used. If supported by the API, display contrast will be used as reported. inf contrast specifies display with perfect black level, in practice OLED. (Only for --vo=gpu-next)"

"--target-trc=<value>
Specifies the transfer characteristics (gamma) of the display. Video colors will be adjusted to this curve when ICC color management is not being used. Valid values are:

auto
Disable any adaptation, except for atypical transfers. Specifically, HDR or linear light source material gets automatically converted to gamma 2.2, while SDR content is not touched. (default)
bt.1886
ITU-R BT.1886 curve (assuming infinite contrast)"

this is the stuff i mean...

[DragonQ]

Can I get around the AMD Radeon 5000/6000 series deinterlacing bug by installing my old RX 480 or RX Vega 56 into my desktop and using that device for deinterlacing? Ideally without plugging any monitors into it. I feel like it might be doable with LAV Filters + madVR but not sure.

[tp4tissue]

That would be an interesting way to solve the problem if it works, wonder if it's practical since you might be adding 20-50watts just to have it in there doing nothing.

[clsid]

Just do copyback + Yadif.

Copyback is best for Madvr anyway.

[strumf666]

I was trying something similar, when 5xxx series lost the fluid motion, added a rx580 as a second graphics card.
It worked with certain limitations, iirc headless running wasn't a problem but everything madvr related could only run a single gpu so I had to significantly reduce the quality if I wanted to use the fluid motion which made it useless for me.

[tp4tissue]

Fallen out of love with smooth motion, adds too much blur.

Newer displays have universal support for 100,120,144.

[huhn]

2 GPU do not work with load sharing when the target is deint on amd.

assuming cuvid and nvidia wouldn't be broken it would work with one additional nvidia also killing detelecine in the process.
yadif is also no practical choice you will loose detelecine and it is really not that great.
as long as deint is broken there is no much that can be done here maybe just maybe look into high end software deint with avisynth as a source.

[DragonQ]

Just do copyback + Yadif.

Copyback is best for Madvr anyway.
YADIF just isn't as good as GPU vector adaptive IME. If there was another option I'd happily use it though.

[Z2697]

GPU has that? What? I thought it was just bob.

[huhn]

a fully function GPU deint has it all.

frame adaptive with field matching. they where really good.

you could literally throw 3:2 at it and it will fieldmatch it properly with full resolution.
still worse then true IVTC cause they will just fieldmatch and do not decimate so you get massive judder but still.

on amd these days it is pretty much bilinear bob and when the driver has a bad day NN. cuvid is also broken and fieldmatching doesn't work with it so pretty much just bob too. but a working GPU deinterlacer could handle hybrid content quite well.

there are much more bugs but you know.

[DragonQ]

GPU has that? What? I thought it was just bob.

nVidia had vector adaptive for yonks, my GT 1030 did that perfectly. AMD had it for yonks too but broke it in their 5000 & 6000 series GPUs (I assumed it was a driver issue but given it's never been fixed and supposedly works again in the 7000 & 9000 series cards, I now think it's a hardware issue).

I could probably shove my GT 1030 in my desktop and use CUVID in LAV Filters but as someone pointed out above, that might mean having to do all MadVR processing on that card too, which would suck? Also having AMD and nVidia drivers on the same machine feels like asking for trouble.

I personally don't care about telecine as I'm in PAL-land, but I have plenty of interlaced content to worry about (1080i/25 and 576i/25 mostly).

[Columbo]

Not sure how relevant it is to your use case but DGSource() with deinterlace=1 (or 2) will give you NVDec adaptive deinterlacing.

[huhn]

the first AMD driver to break deint was the first crimson driver for the 480. after that they fixed it sometimes.

on my 5700 xt it worked from time to time like every 20 tries and only as long as no seek was done.

i tested my 9060 xt even with the hack from mpcVR and it never worked ever.

[purplebaby]

After updating to 596.49 nvidia gpu drivers (have a rtx 5090), hdr content displays 100% black in mpc-hc, on both my displays (ips monitor via displayport, oled tv via hdmi). Any advice?

No other errors. HDR worked fine on previous drivers (which were from 2025).

[Sunspark]

I think software IVTC is the most reliable way to proceed. Why wouldn't you use it all the time? Unless of course, we're talking TV tuner stuff, in which case you don't need IVTC.

Smooth motion, I agree about the blur. Even with a 100 Hz monitor like the one I am sitting at currently, it's not an issue because 23.976 can easily be multiplied 3x and 4x.

On the old 768p TV here it's more complicated, at desktop resolution it won't allow use of anything other than 59.940 or 60. So, smooth motion or pull down are the choices. But, it does allow receiving a 1920x1080 signal at 23.976, so I do that instead for two reasons. One being, letting it downscale to panel is pretty close, if not the same, as super-sampling like how in madvr people were upscaling larger than their panel with image doubling, and then downscaling again. The other being, I haven't noticed any hitching in motion, so I think, but I am not sure, that the processor is running the panel at 47.952 or 48 when it receives that input. This is only a guess, the official manual says for 1920x1080 input it will accept 24 Hz and lists vfreq 24.000 Hz hfreq 27.000 kHz pixel clock 74.250 MHz so I don't know what it's doing. I don't think it can actually clock the panel that low but I don't see the hitch on motion.

[Z2697]

the first AMD driver to break deint was the first crimson driver for the 480. after that they fixed it sometimes.

on my 5700 xt it worked from time to time like every 20 tries and only as long as no seek was done.

i tested my 9060 xt even with the hack from mpcVR and it never worked ever.

No wonder, I never seen true power of GPU deint because I started using "good video players" when it was RX 480 era.

[huhn]

EVR was using it all the time.

[Sunspark]

RDNA2 Linux drivers doesn't have working deinterlace for what it's worth. Strange that they never really fixed it because TV is still broadcast interlaced.

[DragonQ]

But what software deinterlacers are available that are seamless with playback using madVR other than YADIF and Weston Three Field?

[tp4tissue]

How's the new bobweaver option in lavfilter? Ne gud?

[Rob105]

I need to load .cube LUT in madVR it only supports MadVR 3dlut file (.3dlut) and eeColor 3dlut file (.txt) i tried to find way to convert .cube to this formats without luck please advice.

Trying to use .cube LUT for the PotPlayer if theres another way without madVR i could use that as well.

[huhn]

the cube is create from an icm take that to create a proper 3d lut.
there are other ways too but again a bit complicated and depending on what the cube is supposed to do may or may not work.

[DragonQ]

What settings am I supposed to use to get proper colours on my SDR monitor for HLG BT.2020 content? If I use MPC Video Renderer, the colours look more similar to the BT.709 version of the same content and closer to what my HDR TV looks like. If I use madVR, the colours are a bit washed out (oranges and reds especially) but every setting I can find makes no difference, e.g. the HDR settings.

HD MPC/madVR: https://thumbs2.imgbox.com/27/c5/WkNnr1QL_t.png (https://imgbox.com/WkNnr1QL)
madVR Debug: https://thumbs2.imgbox.com/49/58/woB5o0Js_t.png (https://imgbox.com/woB5o0Js)
UHD madVR: https://thumbs2.imgbox.com/d6/c0/FmLZcZZy_t.png (https://imgbox.com/FmLZcZZy)
UHD MPC: https://thumbs2.imgbox.com/1d/b4/5xatxUCL_t.png (https://imgbox.com/5xatxUCL)

[huhn]

madVR doesn't support HLG it uses fall back treat as SDR.

mpcvr has an HLG to SDR convert i never check how accurate that is. it's similar to real tone mapping.

they all look pretty wrong i have to say.

[DragonQ]

madVR doesn't support HLG it uses fall back treat as SDR.

mpcvr has an HLG to SDR convert i never check how accurate that is. it's similar to real tone mapping.

they all look pretty wrong i have to say.
Hmm, that's annoying. Not sure I want to switch renderers for different types of content all the time.

For what it's worth, the HD SDR stream looks very similar to the HDTV SDR broadcast: https://thumbs2.imgbox.com/fd/b1/0ar5Vork_t.png (https://imgbox.com/0ar5Vork)

But all the HD sources look horrible because the bright orange just blurs into mush.

[QBhd]

To be honest... that orange was crazy... even the 720P Fox broadcast OTA antenna gave my OLED fits, and made it look like it was set on an overblown Vivid setting. I would not worry too much about that particular match...

QB

[kasper93]

the greyscale is on libplacebo indirectly confirmed where it is directly confirmed that the image changes in a way it shouldn't. this is something a video render should never ever do.
the error was BTW. over 2 with itp measured with a meter. if you have a calibrated device and use mpv you have now uncalibrated it.

that was with ffmpeg not mpv. it was close without been fixed by the person opening it. nothing was found except that the output is wrong.

i had a direct report about this. i supposedly didn't do it correct and ask why i do wrong int he report now answer.

but yes i never saw haasn ever ignoring an issue but that doesn't mean i will try to report them. i do not have the skills for that. i can easily find issue but when it goes down to the really deep part i have no clue why they actually happen.

mpv and libplacebo have a massive issue where features are added left and right but barely any are actually finished completely.

then there is naming..
we have for transfer function

gamma, trc and transfer to be honest maybe more. yes PQ is sometimes a gamma. and that's ok if it would be consistent.

then bt 1886 was added something madVR can not do and it was hard coded to 1000 CR back in the day making it pointless.
but you can take it off a list...

after testing 1 bit dithering i gave up. i tried all algorithm i could find and all just use a dumpster pixel breaking the point of dithering in the first place.

then there was a feature with getting 420 to the screen function. which was just handsdown fake it's upscaled and then downscaled again. why is such a niche thing added. don't get me wrong i do not need this function i would have used it for ease of use but that's it i don't need it and i think 99.99% user don't need it.

Buddy, if you can't produce any proof or link any report describing the issues, then stop rambling and spreading misinformation, intentionally or not, because I don't think you understand how things work.

[huhn]

Buddy, if you can't produce any proof or link any report describing the issues, then stop rambling and spreading misinformation, intentionally or not, because I don't think you understand how things work.

just call it misinformation that's easier right...
https://github.com/haasn/libplacebo/issues/240

cause i can't proof anything. have an easy one:
dither-depth=1
dither-size-fruit=8

and just to be clear the issue isn't that there are white dots it's where they are.

also try dither-size-fruit=2 the result is "interesting".
edit: sorry i used the free attachment i will fix it sorry.
https://ibb.co/V0M7XZ49
https://ibb.co/6csqG4PV

they have been deleted mistakes have been made.

[nevcairiel]

Unless you use error diffusion (which is always a bad idea for video as its super unstable, and expensive to boot), dithering doesn't even know whats going on in any neighboring pixels, so a "dump pixel" is a literal impossibility. All it does is either pre-generate (eg. blue noise) or compute on the fly (ordered fixed noise, white noise) values to be added to the pixel to either push them to the next higher or next lower value.

[huhn]

i can not argue with technical stuff. but i can tell you all algorithm have that same issue (that test is also been years but yes i tested them >all<). if there is an error they will use this one pixel first and depending on the dither size you can move the grid around.

the issue is they all decide to use the same pixel relative to the grid they work in.

i do not use error diffusion but that sounds interesting that it is bad for video.

i also checked accurate while i was doing this. i only tested one type of patch after using the update function.

madVR ordered dither had an error ~+0.05
mpv size 8 (didn't change it back cause it is used to demonstrate the grid) fruit had -0.7
mpv flyod had an error that is at best 0.01

the white pixel number is technically a bug but so is selecting 1 bit.

[nevcairiel]

I did some tests with dithering to low bitdepth, and the issue with the regular dots only appears on <= 4 bits, which has a special code path to deal with gamma differently, because the low number of values really make gamma harder to handle (otherwise stuff gets very bright). If you skip that path, the dots disappear. So tests with <= 4 bits don't actually translate to any experience with > 4 bits, which most people would be using.
Maybe we can figure out why the dots appear in the first place, but since they wouldnt occur on 5+ bits, its probably not that important.

Actually two zoomed in images from the black bar of a movie:

4bit: https://i.ibb.co/yFh3Wy23/6vvfvbg.png - you can see the regular pattern of dots (well there is only 4 here, but as seen otherwise its all over the black bar)
5bit: https://i.ibb.co/5XDQgkK0/0kbav-Y9.png - random dot noise

The dots appear pretty bright because its shifted up to full 8 bit, so the lowest value any pixel can be (other then 0) is correspondingly higher.
I'm not sure why the black bar doesn't remain fully black, but the movie was HDR, so maybe something in tone mapping or black point correction pushed it up ever so slightly. Tone mapping isnt tweaked on my system as I largely use HDR passthrough, but that wasn't good for testing low bitdepth dithering :P

[huhn]

i tested a plain 100 black png 3 % of all pixel where 1 with
dither-depth=8
dither=fruit
dither-size-fruit=2

that's pretty bad even if the pixel error is just 0.03 by changing the avg pixel from 0 to 0.03 in terms of % that a lot.
this issue was report for madVR too but was fixed.
there where so unbelievable many i could not see the grid.

i tried dither-size-fruit=8 next the error was to massive to find the grid.
so i used 7 massive levels of noise mathematical still 0.03 according to Irfan view that means halve the noise but as 2.
6: avg pixel 0.03 again it aims for that number there is something very wrong going on. it was again to much noise to see a grid.

and i'm ignoring the brightness of the pixel here. gamma corrected dithering should lower the avg image values if it dithered to 2 cause two is much more then twice as bright as 1.

7 and 6 are very sane level of bit deep rare but sane the result is that's just wrong. i can make an MPV thread and and list more of these niche stuff i found over the past 5 years.
maybe it's my system or what ever not doing a general claim here.

[Z2697]

It's hard to figure out what input is like with your description...

[huhn]

0. as a png.

[Z2697]

in what depth?

[huhn]

8 the image is linked above. https://ibb.co/V0M7XZ49 i simply didn't share it again.

[Z2697]

That would be from resizing not dithering (or not only, but combined), somehow.
Verify with --video-unscaled=yes.

And there's something specific about "non standard" resolution.
Correction, it's alpha channel.

[huhn]

what scaler can add error with 0 as input?

[Z2697]

Just drop it.
You don't like mpv it's fine. Don't act like someone forced you to like it.
Maybe some will care, but I can speak for myself that now there's one less person care about your mpv/libplacebo problem.

[nevcairiel]

I looked over the dithering logic and the values it uses, and other then the special 4bit and below logic, which seems a bit weird, the dithering seems fine. If you see that many non 0 pixels my guess is that the values become inaccurate in another step, and dithering does what its designed to do, and preserves even fractional differences.

My own renderer with libplacebo can't be used with images, but I guess i can convert it into a black rgb video a bit later to see if i get any errant pixels. At least I can more closely control what it does exactly.

[huhn]

it really is the presence of an alpha channel. the scaler doesn't seem to matter what so ever. it also didn't matter when i checked y 103 to fullrange rgb 102.3 at native 1080p or UHD.

[Z2697]

I looked over the dithering logic and the values it uses, and other then the special 4bit and below logic, which seems a bit weird, the dithering seems fine. If you see that many non 0 pixels my guess is that the values become inaccurate in another step, and dithering does what its designed to do, and preserves even fractional differences.

My own renderer with libplacebo can't be used with images, but I guess i can convert it into a black rgb video a bit later to see if i get any errant pixels. At least I can more closely control what it does exactly.

It's the alpha channel, sure that's a problem. but I don't care, I don't watch videos half transparant.
If you convert it to RGB video it should be using like FFV1 or FFVHUFF to get the alpha. (ARGB/RGBA/BGRA/GBRA, so many choices!)
But LAVFilter don't pass alpha channel right?
You should just use mpv to test it.

[nevcairiel]

I generally ignore alpha in video as early as possible. There may be some uses for it, but none ever interested me.

[huhn]

to re test this i need to create a different type of test file i see.
while that alpha stuff is a bug the png or other alpha related source are rare.

that's typical again i step into that. if i used a video test pattern that wouldn't have happened.

my answer was written before i saw the alpha part.

only errors at 6 bit and more should matter. i see 1 bit only useful to test dither algorithm but they don't need to be perfect for that.

maybe a 16 bit image with 1 as value is something i can create and then i dither that to 8 bit that may does something similar as 4 bit or lower to test that.

isn't there a windows DS filter that creates an video from image?

[Z2697]

But why, you have FFmpeg lavfi color source, and RGB48 support.

Well, "color" assumes 8-bit RGB value, but you have "lut" to coerce it into existence.

[kasper93]

cause i can't proof anything. have an easy one:
dither-depth=1
dither-size-fruit=8

and just to be clear the issue isn't that there are white dots it's where they are.

also try dither-size-fruit=2 the result is "interesting".
edit: sorry i used the free attachment i will fix it sorry.
https://ibb.co/V0M7XZ49
https://ibb.co/6csqG4PV

they have been deleted mistakes have been made.

I don't need proof or you do diagnose the issue, I need coherent report with what you do to arrive at the wrong result. Not every issue is the same issue. When you generalize things it makes it hard to know what is going on, what is expected and how to reproduce the issue.

I don't have problem with fixing issues, but I don't want to randomly go on a forum thread about madVR, look inside, and see it's just "mpv bad' thread. And then trying to unwrap what is going on.

And even after trying to figure out, I can't, because images are removed, there are inconsistent claims and I don't even know if you output to PQ swapchain or SDR one.

I could go on and explain, why the lifted black may happen, and how it's below what you can see, unless you do `dither-depht=1`, which you don't. But I don't want to muddy the discussion, because I'm not sure what part of the problem is affecting you.

Correction, it's alpha channel.

Could you say what images and output did you compare to get this conclusion? I could reproduce lifted black, only in completely different scenario.

Also note guys, that `mpv image.jpg` will look different for each of you likely, mpv does infer display parameters, adapt to that the image. It depends on your configuration, both in system and mpv.

[huhn]

I don't need proof or you do diagnose the issue, I need coherent report with what you do to arrive at the wrong result. Not every issue is the same issue. When you generalize things it makes it hard to know what is going on, what is expected and how to reproduce the issue.

I don't have problem with fixing issues, but I don't want to randomly go on a forum thread about madVR, look inside, and see it's just "mpv bad' thread. And then trying to unwrap what is going on.

And even after trying to figure out, I can't, because images are removed, there are inconsistent claims and I don't even know if you output to PQ swapchain or SDR one.

I could go on and explain, why the lifted black may happen, and how it's below what you can see, unless you do `dither-depht=1`, which you don't. But I don't want to muddy the discussion, because I'm not sure what part of the problem is affecting you.



Could you say what images and output did you compare to get this conclusion? I could reproduce lifted black, only in completely different scenario.

Also note guys, that `mpv image.jpg` will look different for each of you likely, mpv does infer display parameters, adapt to that the image. It depends on your configuration, both in system and mpv.
i wrote it intentionally in a way to not blame it directly or absolute that it could be improved. no image has been removed they have just been placed as a link instead of attachment that used full resolution as preview.

there is more. https://github.com/mpv-player/mpv/issues/13468
i can't write an error report now i'm silenced problem solved?

was ACM an issue in 2024? so mpv has absolutely nothing to do with it? i don't know. i only remember that the RGB balance was wrong and the image had a to green tint similar to the other report also that my meter didn't like it what so ever.

i can tell you so much more broken stuff from madVR argyllcms 3D LUT been broken and produce massive discoloration under specific situations. madshi said it is a 3D LUT issue displaycal dev said it is a madVR issue. never fixed in any of them but a WTW/BTB clipping shader does fix it.

i know about VRR issues with mpv. it just send 25 even through 99.5% of all devices have a min fps of 48 so it is always using LFC while it could easily do fps*(max HZ /current FPS truncated down).
current result is 50-150 (guess cause it shows 144) and it is flickering like crazy which is a display issue. lfc is a marketing lie most people know that.

BTW. depending on what that actually means and how far that goes. "Also note guys, that mpv image.jpg` will look different for each of you likely, mpv does infer display parameters, adapt to that the image. It depends on your configuration, both in system and mpv"
calibration as a concept would be dead. pgen exists to bypass stuff like that. if it reads HDR and SDR is played and instead of using the OS/driver SDR -> HDR conversation it is doing it on it's own as this is needed on windows that is a different story.

[Z2697]

Could you say what images and output did you compare to get this conclusion? I could reproduce lifted black, only in completely different scenario.

ffmpeg -f lavfi -i color=0x000000,format=rgb{a,24} -frames 1 test.png

mpv test.png --dither-depth=1 --no-config --target-colorspace-hint=no

Then make scaling active by resizing window or anything.

(Yes it's very unlikely to happen in real life scenario)

[kasper93]

i wrote it intentionally in a way to not blame it directly or absolute that it could be improved. no image has been removed they have just been placed as a link instead of attachment that used full resolution as preview.

The links didn't work for me at the time. All good.


there is more. https://github.com/mpv-player/mpv/issues/13468
i can't write an error report now i'm silenced problem solved?


You shouldn't be blocked. I think you might have been at some point, other org members are not very patient. I may be sometimes abrasive, but I generally don't mean bad and always try to get to the bottom of things.


was ACM an issue in 2024? so mpv has absolutely nothing to do with it? i don't know. i only remember that the RGB balance was wrong and the image had a to green tint similar to the other report also that my meter didn't like it what so ever.

Screenshots are not the best way to evaluate quality. Because they go through, unrealistic pipeline, especially in gpu-next. It renders to rgba64 and then converts it to target image with swscale or zimg. Either way, I can look into this. Those however are corner cases and not real playback issues.


i know about VRR issues with mpv. it just send 25 even through 99.5% of all devices have a min fps of 48 so it is always using LFC while it could easily do fps*(max HZ /current FPS truncated down).
current result is 50-150 (guess cause it shows 144) and it is flickering like crazy which is a display issue. lfc is a marketing lie most people know that. VRR is not supported. Disable it for mpv. Use `--video-sync=display-resample` for sync to vsync. IIRC there are workarounds for VRR, like using different swap interval. EDIT: you can `--vf=fps=144` to output at specific rate.


BTW. depending on what that actually means and how far that goes. "Also note guys, that mpv image.jpg` will look different for each of you likely, mpv does infer display parameters, adapt to that the image. It depends on your configuration, both in system and mpv"
calibration as a concept would be dead. pgen exists to bypass stuff like that. if it reads HDR and SDR is played and instead of using the OS/driver SDR -> HDR conversation it is doing it on it's own as this is needed on windows that is a different story.
If your display is calibrated to a target that doesn't match EDID, you have to specify this target using mpv options. Same as in madVR you have to select "display is already calibrated ..." option. Additionally nowadays displays are factory calibrated, with reasonable results, so targeting the luminance and gamut that they report as native is genially good for 99% of users. Also you can use ICC profile in mpv or 3dlut.

ffmpeg -f lavfi -i color=0x000000,format=rgb{a,24} -frames 1 test.png

mpv test.png --dither-depth=1 --no-config --target-colorspace-hint=no

Then make scaling active by resizing window or anything.

(Yes it's very unlikely to happen in real life scenario)

Thanks, I see it. Generally this all stems form the fact that internal representation is absolute linear in libplacebo, so SDR input is black lifted there and then reduced back down to 0, but if you have some processing that adds noise above black it may not round-trip. I can look at this specific case, but again this isn't that common scenario.

[huhn]

Screenshots are not the best way to evaluate quality. Because they go through, unrealistic pipeline, especially in gpu-next. It renders to rgba64 and then converts it to target image with swscale or zimg. Either way, I can look into this. Those however are corner cases and not real playback issues.
i use alt+print do they also bypass the normal pipeline?
VRR is not supported. Disable it for mpv. Use `--video-sync=display-resample` for sync to vsync. IIRC there are workarounds for VRR, like using different swap interval. EDIT: you can `--vf=fps=144` to output at specific rate.
if it is not supported then it doesn't need to work. i only remember that it triggered automatically there was even an option to avoid it. it's currently killed using EDID overrides so i do not remember the option.

just for reference i needed to playaround with nvidia inspector mpc-hc to allow vrr. i also needed hack the exe so nvidia wouldn't know this is mpc-hc. mpv is not driver blocked.
If your display is calibrated to a target that doesn't match EDID, you have to specify this target using mpv options. Same as in madVR you have to select "display is already calibrated ..." option. Additionally nowadays displays are factory calibrated, with reasonable results, so targeting the luminance and gamut that they report as native is genially good for 99% of users. Also you can use ICC profile in mpv or 3dlut.

that's madVR specific but you have to do nothing. madVR assumes bt709 and may mess up bt 601 but that's it also assumes a gamma of 2.2. the assumption of 2.2 is up to this day an inconvenience that can not be easily over come people wanted that to be 2.4 over and over again.

while screen are out of the box much better these days they are still very problematic.
that's why ACM is so funny. yes my S90C is supposedly "reference" (not my words) out of the box if you ignore gamma but with ACM it is broken cause the edid has most likely native gamut information in it or worse... so if screen are calibrated these days you shouldn't trust edid or what ever. just saying.
Thanks, I see it. Generally this all stems form the fact that internal representation is absolute linear in libplacebo, so SDR input is black lifted there and then reduced back down to 0, but if you have some processing that adds noise above black it may not round-trip. I can look at this specific case, but again this isn't that common scenario.

i took the image striped the alpha channel und redid the test. it is black now as it should be. it is really the alpha channel. you also need to scale but the alpha channel is the common nominator. making the risen black an insanely rare issue. i only wanted to show the grid BTW.

there is still maybe an issue. it targeted 0.03 as a pixel value at 8 7 and 6 bit meaning 6 bit is not gamma corrected to get a similar bright image the value should be lower at lower bit deep(close to black at least) to avg to something lower then 0.03 that has a similar brightness as 8 bit 0.03. but i need to trigger that without an alpha channel cause who knows what is really happening.

[DragonQ]

By the way, while trying to make my own 1080p SDR versions of the 2160p HLG footy highlights, it seems that using "zscale=tin=arib-std-b67" produces horrible results (kind of similar to the officially provided "1080p" SDR stream but with more intense colours, which might be tweakable). Using libplacebo tonemapping produces very similar results to the MPC Video Renderer, which looks far better overall (IMO at least).

[Z2697]

By the way, while trying to make my own 1080p SDR versions of the 2160p HLG footy highlights, it seems that using "zscale=tin=arib-std-b67" produces horrible results (kind of similar to the officially provided "1080p" SDR stream but with more intense colours, which might be tweakable). Using libplacebo tonemapping produces very similar results to the MPC Video Renderer, which looks far better overall (IMO at least).

For that "naive" version of conversion, you can raise the npl, default is 100 (probably).
*it will cause the resulting image to be darker overall, but can avoid clipping in high brightness.

But yeah libplacebo should be the go-to choice of tonemapping filter in FFmpeg and Synth's.

[DragonQ]

For that "naive" version of conversion, you can raise the npl, default is 100 (probably).
*it will cause the resulting image to be darker overall, but can avoid clipping in high brightness.

But yeah libplacebo should be the go-to choice of tonemapping filter in FFmpeg and Synth's.
It does surprise me that the SDR "layer" of HLG looks so rubbish when I thought that was the entire point of HLG in the first place (to be backwards compatible with SDR)!

[Columbo]

It does surprise me that the SDR "layer" of HLG looks so rubbish when I thought that was the entire point of HLG in the first place (to be backwards compatible with SDR)! Ditto +1

My TV switches to HDR HLG to play a stream but when I invoke menus everything is flat and gray. Maybe it's a different issue entirely?!

[Z2697]

I *think* it's not meant to be naively converted to the BT709 tranfer, it meant to be played as if it were BT709 transfer. (of course what it really meant is to be played as HDR...)
The conversion inevitably needs to deal with the higher brightness, while playing "as is" have the high brightness squished at the top of the curve (and all well within range of course).

But aparently with HDR things are just not right, (yet?)
Standards, content creators, display manufacturers, video players, OS's, drivers, etc...
Not everyone agree to each other...

Edit: actually I was just assuming the problem is the conversion, the "zscale=tin=arib-std-b67" *alone* won't do the conversion.
Another aspect is movies these days rarely reach very high brightness (sadly?), typically uses PQ.
But the HLG that comes out of some camera will readily shine some flash grenade, especially when shooting in bright day light.
(Movie cameras probably would too, but the difference is the post?)
It's not tied to the transfer function itself.

[kasper93]

ffmpeg -f lavfi -i color=0x000000,format=rgb{a,24} -frames 1 test.png

mpv test.png --dither-depth=1 --no-config --target-colorspace-hint=no

Then make scaling active by resizing window or anything.

(Yes it's very unlikely to happen in real life scenario)Thanks, I see it. Generally this all stems form the fact that internal representation is absolute linear in libplacebo, so SDR input is black lifted there and then reduced back down to 0, but if you have some processing that adds noise above black it may not round-trip. I can look at this specific case, but again this isn't that common scenario.

This and few other issues, should be fixed by https://code.videolan.org/videolan/libplacebo/-/merge_requests/867

[nevcairiel]

It does surprise me that the SDR "layer" of HLG looks so rubbish when I thought that was the entire point of HLG in the first place (to be backwards compatible with SDR)!

You get nothing for free, to squeeze in some HDR data you sacrifice some SDR quality. HLG as a format is a huge compromise that ruins both options.

[huhn]

can it not be put relatively lossless into PQ? or is the HDR part that destructive stored?

still think it is a terrible format but it has a range of 0 to 1000 nits oddly rolled of isn't that about it?

[huhn]

This and few other issues, should be fixed by https://code.videolan.org/videolan/libplacebo/-/merge_requests/867

you changed the black floor detection while that is an issue with 1 bit and slightly noisy source libplacebo didn't rise the black what so ever after removing the alpha channel. the risen black floor is coming from scaling the alpha channel image and for what ever reason coming up to 0.3 which is quite high and dithering is trying to preserve that 0.3 is way way to big for float point errors there is something bigger going on with alpha channel.

8 bit dither seems to be just fine on a normal source.

[nevcairiel]

There is a number of changes in there, including fixing ortho scaling to better preserve power in the first place - which is what caused alpha to get "noisy" in the first place.

[kasper93]

you changed the black floor detection while that is an issue with 1 bit and slightly noisy source libplacebo didn't rise the black what so ever after removing the alpha channel. the risen black floor is coming from scaling the alpha channel image and for what ever reason coming up to 0.3 which is quite high and dithering is trying to preserve that 0.3 is way way to big for float point errors there is something bigger going on with alpha channel.

8 bit dither seems to be just fine on a normal source.

When I'm testing something, I might as well fix other issue that I deem fixable. Let me know of any remaining issues with mpv/libplacebo that you have, thanks.

There is a number of changes in there, including fixing ortho scaling to better preserve power in the first place - which is what caused alpha to get "noisy" in the first place.

Correct, this was the main fix for alpha. The rest of the fixes are mostly biksheeding of PQ output where the lifted black could be observed too. And bt.1886 fix for infinite contrast. Overall those are cases, that I could reproduce myself and fixed.

[pirlouy]

@kasper93: That's nice of you, for those of us who don't want to be lynched by angry mpv github contributors. But I guess it would be more appropriated in mpv thread. I will bring one back.
If you confirm a problem, we could fill an issue in the tracker.

[Rob105]

the cube is create from an icm take that to create a proper 3d lut.
there are other ways too but again a bit complicated and depending on what the cube is supposed to do may or may not work.

I have no ICM i download cube from a website i need to have that converted to ICM then to the 3dlut but what about 3dlut format madvr supports i could not find any tool that produces that format.

[huhn]

a cube is a 3D LUT.

argylcms will be able to convert icm (it supported version) to madVR 3D LUT.

an icm is technically better then a 3D LUT a 3d LUT is only interesting if you have an ICM file and want to apply calculation on it that can not be done properly in real time. taking a random cube and wanting to use that is most likely not how you should do any of that.

[tp4tissue]

I'm running 25H2 Bug city.

Does anyone know if dxva2 or dxva2 copy back works for AV1 4K60fps through lav and into madvr, it seems like it works with dx11 but not either dxva2.

On AMD.

[mclingo]

given that the main MAD VR thread has now been shut down from here.

please can someone remind me what the prerequisites are for playing 3D and MVC movies, I can't seem to get MadVR to trigger 3D mode on my TV. got everything set as 8 bit got 3D turned on in madvr, call my filters set up media player correctly as it plays 2D movies fine. use direct 3D 11 for presentation is ticked, I have tried it with and without FSE enabled I can't think of anything else. when I play the movie it really goes into 1080p 23976 mode on my TV it does not trigger the 3D mode The movie just plays in 2D

[mclingo]

fixed it for some reason my lav filtres were broken I couldn't see anything wrong with them whatsoever but was on an older version 81xx, I installed 82 and that fixed it

[mclingo]

must have been a fluke worked a couple of times and then stopped working again now probably now it's not playing it into the D is playing it in SBS mode which is even stranger This is a frame packed movie

[tp4tissue]

3D works alot better on Viture type oled glasses, if you want to legacy that content. You get way better contrast and no blurry crosstalk.

It works with Madvr SBS output

[strumf666]

Anybody have issues with madvr lately?
I just upgraded graphics and chipset drivers to the latest 5800x&6900xt (amd_software_8.07.16.1035&whql-amd-software-adrenalin-edition-26.7.1-win11-a) and I can't use madvr anymore, my pc restarts as soon as I start the video. I use mpcBE to play videos.
I tried reverting to the previous drivers but strangely enough it doesn't make a difference. MPC video renderer works normal.

[Klaus1189]

What says eventviewer?

[clsid]

Restart means BSoD.

[strumf666]

Yes, bsod, I don't know where/what to look for in regards to logs or eventviewer. Any advice how to do that?
edit: Does this help:
The computer has rebooted from a bugcheck. The bugcheck was: 0x00000124 (0x0000000000000000, 0xffffe487c405a028, 0x00000000bc000800, 0x0000000001010135). A dump was saved in: C:\WINDOWS\Minidump\080626-10281-01.dmp. Report Id: 2ce28358-3d68-4103-a622-0c51ba25a556.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
nt!_WHEA_ERROR_RECORD structure that describes the error condition. Try !errrec Address of the nt!_WHEA_ERROR_RECORD structure to get more details.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: ffffe487c405a028, Address of the nt!_WHEA_ERROR_RECORD structure.
Arg3: 00000000bc000800, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000001010135, Low order 32-bits of the MCi_STATUS value.

Debugging Details:
------------------

*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: hal!_WHEA_MEMORY_ERROR_SECTION ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: hal!_WHEA_MEMORY_ERROR_SECTION ***
*** ***
*************************************************************************

KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 1937

Key : Analysis.Elapsed.mSec
Value: 9496

Key : Analysis.IO.Other.Mb
Value: 13

Key : Analysis.IO.Read.Mb
Value: 1

Key : Analysis.IO.Write.Mb
Value: 32

Key : Analysis.Init.CPU.mSec
Value: 687

Key : Analysis.Init.Elapsed.mSec
Value: 52604

Key : Analysis.Memory.CommitPeak.Mb
Value: 104

Key : Analysis.Version.DbgEng
Value: 10.0.29617.1000

Key : Analysis.Version.Description
Value: 10.2604.29.1 amd64fre

Key : Analysis.Version.Ext
Value: 1.2604.29.1

Key : Bugcheck.Code.LegacyAPI
Value: 0x124

Key : Bugcheck.Code.TargetModel
Value: 0x124

Key : Dump.Attributes.AsUlong
Value: 0x1808

Key : Dump.Attributes.DiagDataWrittenToHeader
Value: 1

Key : Dump.Attributes.ErrorCode
Value: 0x0

Key : Dump.Attributes.KernelGeneratedTriageDump
Value: 1

Key : Dump.Attributes.LastLine
Value: Dump completed successfully.

Key : Dump.Attributes.ProgressPercentage
Value: 0

Key : Failure.Bucket
Value: 0x124_0_AuthenticAMD_MEMORY__UNKNOWN_FATAL_IMAGE_AuthenticAMD.sys

Key : Failure.Hash
Value: {b0905187-9dbc-d607-4dc5-8630b9eddb7f}

Key : Hypervisor.Enlightenments.ValueHex
Value: 0x7497cf94

Key : Hypervisor.Flags.AnyHypervisorPresent
Value: 1

Key : Hypervisor.Flags.ApicEnlightened
Value: 1

Key : Hypervisor.Flags.ApicVirtualizationAvailable
Value: 0

Key : Hypervisor.Flags.AsyncMemoryHint
Value: 0

Key : Hypervisor.Flags.CoreSchedulerRequested
Value: 0

Key : Hypervisor.Flags.CpuManager
Value: 1

Key : Hypervisor.Flags.DeprecateAutoEoi
Value: 0

Key : Hypervisor.Flags.DynamicCpuDisabled
Value: 1

Key : Hypervisor.Flags.Epf
Value: 0

Key : Hypervisor.Flags.ExtendedProcessorMasks
Value: 1

Key : Hypervisor.Flags.HardwareMbecAvailable
Value: 1

Key : Hypervisor.Flags.MaxBankNumber
Value: 0

Key : Hypervisor.Flags.MemoryZeroingControl
Value: 0

Key : Hypervisor.Flags.NoExtendedRangeFlush
Value: 0

Key : Hypervisor.Flags.NoNonArchCoreSharing
Value: 1

Key : Hypervisor.Flags.Phase0InitDone
Value: 1

Key : Hypervisor.Flags.PowerSchedulerQos
Value: 0

Key : Hypervisor.Flags.RootScheduler
Value: 0

Key : Hypervisor.Flags.SynicAvailable
Value: 1

Key : Hypervisor.Flags.UseQpcBias
Value: 0

Key : Hypervisor.Flags.Value
Value: 38408431

Key : Hypervisor.Flags.ValueHex
Value: 0x24a10ef

Key : Hypervisor.Flags.VpAssistPage
Value: 1

Key : Hypervisor.Flags.VsmAvailable
Value: 1

Key : Hypervisor.RootFlags.AccessStats
Value: 1

Key : Hypervisor.RootFlags.CrashdumpEnlightened
Value: 1

Key : Hypervisor.RootFlags.CreateVirtualProcessor
Value: 1

Key : Hypervisor.RootFlags.DisableHyperthreading
Value: 0

Key : Hypervisor.RootFlags.HostTimelineSync
Value: 1

Key : Hypervisor.RootFlags.HypervisorDebuggingEnabled
Value: 0

Key : Hypervisor.RootFlags.IsHyperV
Value: 1

Key : Hypervisor.RootFlags.LivedumpEnlightened
Value: 1

Key : Hypervisor.RootFlags.MapDeviceInterrupt
Value: 1

Key : Hypervisor.RootFlags.MceEnlightened
Value: 1

Key : Hypervisor.RootFlags.Nested
Value: 0

Key : Hypervisor.RootFlags.StartLogicalProcessor
Value: 1

Key : Hypervisor.RootFlags.Value
Value: 1015

Key : Hypervisor.RootFlags.ValueHex
Value: 0x3f7


BUGCHECK_CODE: 124

BUGCHECK_P1: 0

BUGCHECK_P2: ffffe487c405a028

BUGCHECK_P3: bc000800

BUGCHECK_P4: 1010135

FILE_IN_CAB: 080626-10281-01.dmp

TAG_NOT_DEFINED_202b: *** Unknown TAG in analysis list 202b


DUMP_FILE_ATTRIBUTES: 0x1808
Kernel Generated Triage Dump

FAULTING_THREAD: ffffe487d0e56080

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1 (!blackboxwinlogon) (!blackboxwinlogonnotify)


CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

STACK_TEXT:
ffffab00`e873d948 fffff801`8873be00 : 00000000`00000124 00000000`00000000 ffffe487`c405a028 00000000`bc000800 : nt!KeBugCheckEx
ffffab00`e873d950 fffff801`1a0b12a0 : 00000000`00000000 ffffab00`e873da19 ffffe487`c405a028 ffffe487`c2cfd450 : nt!HalBugCheckSystem+0xc0
ffffab00`e873d990 fffff801`888e5f5f : 00000000`00000000 ffffab00`e873da19 ffffe487`c405a028 ffffab00`e8711180 : PSHED!PshedBugCheckSystem+0x10
ffffab00`e873d9c0 fffff801`8873da96 : 00000000`0000000d 00000000`0000000d ffffe487`c2cfd4a0 ffffe487`c2cfd450 : nt!WheaReportHwError+0x2c5f2f
ffffab00`e873da80 fffff801`8873de50 : 00000000`0000000d ffffe487`00000003 ffffbd8f`69049000 ffffbd8f`69050000 : nt!HalpMcaReportError+0xb2
ffffab00`e873dbf0 fffff801`8873dc6a : 00000000`0000000d 00000000`00000000 ffffab00`e873de00 00000000`00000000 : nt!HalpMceHandlerCore+0x138
ffffab00`e873dc50 fffff801`8873d13e : ffffab00`e873de60 ffffab00`e873def0 00000000`0000000d 00000000`00000000 : nt!HalpMceHandler+0x66
ffffab00`e873dc90 fffff801`88740a3b : ffffab00`e873de60 00000000`00000000 00000000`00000000 00000000`00000000 : nt!HalpHandleMachineCheck+0x96
ffffab00`e873dcc0 fffff801`887b4be9 : ffffe487`e4283010 00000000`00000000 00000000`00000000 00000000`00000000 : nt!HalHandleMcheck+0x6b
ffffab00`e873dcf0 fffff801`888bc07e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiHandleMcheck+0x9
ffffab00`e873dd20 fffff801`888bbc99 : 00000000`00000010 00000000`00000000 00000000`00000000 ffffe487`e4283010 : nt!KxMcheckAbort+0x7e
ffffab00`e873de60 fffff801`1b95b618 : ffffe487`c8fafd38 ffffd38b`1d0a3010 00000000`00000008 fffff801`1b794ed6 : nt!KiMcheckAbort+0x2d9
ffffbd8f`6904f430 fffff801`1b95931d : ffffe487`e4283010 40800000`40000003 00000000`00000000 00000000`00000001 : Ntfs!NtfsHoldIrpForNewLength+0x18
ffffbd8f`6904f480 fffff801`1b9415e1 : ffffe487`dc759778 ffffe487`ca94f930 ffffe487`c8fa1d30 00000000`00000000 : Ntfs!NtfsReadUsnJournal+0xb0d
ffffbd8f`6904f6b0 fffff801`1b940a1b : ffffe487`e4283010 00000000`00000000 00000000`00000000 7fffffff`fffffffc : Ntfs!NtfsUserFsRequest+0xa11
ffffbd8f`6904f700 fffff801`1b9408a3 : ffffe487`c8fafd38 40800000`40000000 ffffe487`e4283010 ffffe487`dc759690 : Ntfs!NtfsCommonFileSystemControl+0x5b
ffffbd8f`6904f7e0 fffff801`8845cabb : 00000000`00000000 ffffe487`e4283010 00000000`00000000 ffffe487`c8fafd38 : Ntfs!NtfsFsdFileSystemControl+0x113
ffffbd8f`6904f870 fffff801`8845ca33 : ffffc480`033e730d 00000000`00000000 00000000`00000000 fffff801`8849a11d : nt!IopfCallDriver+0x5b
ffffbd8f`6904f8b0 fffff801`1a22c70e : fffff801`1e5f1240 ffffe487`dc759690 ffffe487`dc759690 fffff801`1a2275a9 : nt!IofCallDriver+0x13
ffffbd8f`6904f8e0 fffff801`1a22cc41 : ffffbd8f`6904f970 ffffbd8f`00010000 ffffe487`dc759700 ffffbd8f`6904faa8 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe
ffffbd8f`6904f950 fffff801`1e60c109 : ffffe487`dc759778 fffff801`1e5f1240 ffffe487`d4620468 ffffe487`d4620423 : FLTMGR!FltPerformAsynchronousIo+0x3b1
ffffbd8f`6904fa30 fffff801`1e60be1f : ffffe487`d4620430 ffffd38b`1d0a3008 ffffd38b`1d0a3008 00000000`00000000 : luafv!SynchronousFsControl+0x159
ffffbd8f`6904fae0 fffff801`8868212a : ffffe487`d0e56080 ffffe487`d0e56080 fffff801`1e60bce0 024fe07f`b8bbbdff : luafv!UsnThread+0x13f
ffffbd8f`6904fbb0 fffff801`888acd94 : ffffab00`e83e7180 ffffe487`d0e56080 fffff801`886820d0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
ffffbd8f`6904fc00 00000000`00000000 : ffffbd8f`69050000 ffffbd8f`69049000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34


MODULE_NAME: AuthenticAMD

IMAGE_NAME: AuthenticAMD.sys

STACK_COMMAND: .process /r /p 0xffffe487c24bb040; .thread /r /p 0xffffe487d0e56080 ; kb

FAILURE_BUCKET_ID: 0x124_0_AuthenticAMD_MEMORY__UNKNOWN_FATAL_IMAGE_AuthenticAMD.sys

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {b0905187-9dbc-d607-4dc5-8630b9eddb7f}

Followup: MachineOwner

From bluescreenview:
PSHED.dll PSHED.dll+12a0 fffff801`1a0b0000 fffff801`1a0cd000 0x0001d000 0x0b52620b Microsoft® Windows® Operating System Platform Specific Hardware Error Driver 10.0.26100.1 (WinBuild.160101.0800) Microsoft Corporation C:\WINDOWS\system32\PSHED.dll

[clsid]

https://www.nirsoft.net/utils/blue_screen_view.html

That code is WHEA_UNCORRECTABLE_ERROR, a fatal hardware error.

Possibly overheating. Check your cooling and remove dust.

[strumf666]

I added what I found in the original post. Is it usefull?
I have watercooling, so I don't believe temperatures are the issue. GPU hotspot is below 70°C in superposition benchmark, cpu temp as well.

[clsid]

The stack trace in the dump points to a possible file system error.

Run chkdsk (https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chkdsk)

Or right-click on your drive > Properties > Tools > Error-checking

[strumf666]

Thanks, madvr is working again :)
chkdsk report:
Stage 1: Examining basic file system structure ...
1515264 file records processed.
File verification completed.
Phase duration (File record verification): 7.84 seconds.
58488 large file records processed.
Phase duration (Orphan file record recovery): 29.01 milliseconds.
0 bad file records processed.
Phase duration (Bad file record checking): 0.15 milliseconds.

Stage 2: Examining file name linkage ...
969 reparse records processed.
1959224 index entries processed.
Index verification completed.
Phase duration (Index verification): 13.62 seconds.
0 unindexed files scanned.
Phase duration (Orphan reconnection): 2.18 seconds.
0 unindexed files recovered to lost and found.
Phase duration (Orphan recovery to lost and found): 0.17 milliseconds.
969 reparse records processed.
Phase duration (Reparse point and Object ID verification): 5.96 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Phase duration (Security descriptor verification): 43.34 milliseconds.
221981 data files processed.
Phase duration (Data attribute verification): 0.26 milliseconds.
CHKDSK is verifying Usn Journal...
41703800 USN bytes processed.
Usn Journal verification completed.
Phase duration (USN journal verification): 71.38 milliseconds.
The Volume Bitmap is incorrect.
Windows has checked the file system and found problems.
Please run chkdsk /scan to find the problems and queue them for repair.

878965759 KB total disk space.
737205184 KB in 610618 files.
491908 KB in 221982 indexes.
0 KB in bad sectors.
1668187 KB in use by the system.
65536 KB occupied by the log file.
139600480 KB available on disk.

4096 bytes in each allocation unit.
219741439 total allocation units on disk.
34900120 allocation units available on disk.
Total duration: 23.81 seconds (23814 ms).
I ran chkdsk /f after and no more reboots/bsods when running madvr.
I wonder what caused this in the first place; I don't even remember the last time I had a bsod before this, my computer is working fine (occt test 1+h without error, ssd is supposed to be in good condition according to samsung magician).

[dbcooper]

Anyone know if the Windows 11 Hardware Accelerated GPU Scheduling issue has been fixed?

[tp4tissue]

Honestly, if you just go back to win10, 99% problems fixed.

It's not the scheduler, it's the overlay thingie.

[tp4tissue]

I ran chkdsk /f after and no more reboots/bsods when running madvr.
I wonder what caused this in the first place; I don't even remember the last time I had a bsod before this, my computer is working fine (occt test 1+h without error, ssd is supposed to be in good condition according to samsung magician).

Your ram is likely unstable at stock timings. Usually motherboard, the way it interacts and trains. It's causing file system errors throughout daily usage and once that coalesces enough, it goes down.