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.