madVR - high quality video renderer (GPU assisted)

[SamuriHL]

Recommendation? Yes. You will have to put in the work and try the different options to find what looks best to you in your viewing environment and equipment. Personal taste counts here just as much as technical ability of the algorithms. What I might recommend would be wildly different to what others may recommend and depending on your equipment and viewing area may not even be good for you. There's no shortcut to this process. Personally I like the NGU algorithms with my 3080. I like AA for chroma and sharp for upscaling. That's just my personal taste, however. You'll have to try out different options and see what you like.

[scollaco]

Recommendation? Yes. You will have to put in the work and try the different options to find what looks best to you in your viewing environment and equipment. Personal taste counts here just as much as technical ability of the algorithms. What I might recommend would be wildly different to what others may recommend and depending on your equipment and viewing area may not even be good for you. There's no shortcut to this process. Personally I like the NGU algorithms with my 3080. I like AA for chroma and sharp for upscaling. That's just my personal taste, however. You'll have to try out different options and see what you like.

Yes, I have done the work and spent countless hours fine tuning it to my tastes. I guess, I was curious what some recommendations are from others and to see if it lines up with mine.

I ended up with NGU sharp for Chroma and also NGU Sharp for upscaling. I sometimes use NGU AA for chroma but not sure what I like better. I personally prefer sharp images.

[SamuriHL]

That's why it's so subjective and why there's no "best" recommendations. Some people find sharp off-putting. Some people put their TV in vivid mode for that "HDR effect". LMAO People's tastes vary wildly. I like AA for chroma and sharp for upscaling but there was plenty of discussion around that a while back. Some people don't use NGU for choma at all as they feel it's a waste of resources to provide little to no gain. To each their own. There's just too many settings and variables to account for everyone's unique setup. Lord knows madshi has tried. He'd LOVE to simplify the interface and have far fewer options but there is really no consensus. Hell even on the latest HDR test builds trying to solve the luminance algorithm there's no consensus. They'll be doing a blind taste test soon to see what people prefer. I have no doubt at all that there won't be a single unified answer on that one.

[scollaco]

That's why it's so subjective and why there's no "best" recommendations. Some people find sharp off-putting. Some people put their TV in vivid mode for that "HDR effect". LMAO People's tastes vary wildly. I like AA for chroma and sharp for upscaling but there was plenty of discussion around that a while back. Some people don't use NGU for choma at all as they feel it's a waste of resources to provide little to no gain. To each their own. There's just too many settings and variables to account for everyone's unique setup. Lord knows madshi has tried. He'd LOVE to simplify the interface and have far fewer options but there is really no consensus. Hell even on the latest HDR test builds trying to solve the luminance algorithm there's no consensus. They'll be doing a blind taste test soon to see what people prefer. I have no doubt at all that there won't be a single unified answer on that one.

Yes, everything you say makes sense. I was following all the betas for HDR until even 158, 158b and even 159. Ended up going back to v113 as I couldn't tell a difference in my setup. Maybe I'll go back and check it again once things iron out.

[SamuriHL]

I'm not sure it'll ever "iron out". And yes I do know what you mean by that. It's just that the betas at this point are really meant for a very specific group of people who know the bargain being made. The betas help improve the envy while the advanced users can take advantage of the functionality that's being tested. A lot of the testers went back to 113, as well. Once luminance is dealt with I suspect saturation is going to be back on the table and that's going to be ugly...again. Content makes that a very challenging topic and there's no one size fits all answer to that one. But it's all fun.

[Schwartz]

I would say at least for Chroma it's pretty easily reproducible that Bilateral is the top dog. You can do comparisons zoomed in, looking at red-on-color in particular. For image doubling it's NGU. Standard or Soft is still plenty sharp and I don't like artifacts. Image up- and downscaling is more to taste. Any Cubic function, Spline, Jinc are fine options.

Finding a good algo while avoiding ringing is better than going with something too sharp and then doing AR after the fact, but YMMV.

[CZ Eddie]

Hi guys, is it possible to have two separate instances of MadVR? One for each player?
Like, one for MPC-HC and a different one for VideoProcessor?

Because each player would require different settings even when the resolution is the same.

[huhn]

if the player doesn't do that by them self no.
there are more complicated ways to do that with profiles and pretty easy ones with a simple starting script where the script just installs a different version of madVR or replaces the setting.bin.

but i never tried any of these.

[CZ Eddie]

Thank you. I guess the next best option is to setup unique MadVR profiles for each source and then use keyboard shortcuts to switch between them.

[Perenista]

I am currently using the i5 11400 (onboard graphics) and the XV280K-B (4K monitor, at 60 Hz). I was planning on getting the RTX 3060 video card.

Will using this GPU make any difference in terms of watching UHD/4K remuxes or any other video, for that matter, if madVR is chosen (and MPC-BE or MPC-HC)? Can I expect a positive change in that regard? I am also using Win 11 and current RAM is 16 GB. Regular SSD.

I believe with this current setup I can't enable HDR from this monitor without some serious slowdown, for example. As far as I know relying on a CPU like mine isn't going to be enough for simply playing all sorts of content.

This has been hinted in this thread before, but when I asked that question I used the i7 4770 CPU.

[flossy_cake]

I am currently using the i5 11400 (onboard graphics) I was planning on getting the RTX 3060 video card.

Will using this GPU make any difference in terms of watching UHD/4K remuxes or any other video. As far as I know relying on a CPU like mine isn't going to be enough for simply playing all sorts of content.

This has been hinted in this thread before, but when I asked that question I used the i7 4770 CPU.

I think you should be able to play up to 4k30 on that CPU alone, but 4k60 HDR might be a problem as that is where my stock i7-4790k can't keep up. My GTX 1070 can manage it fine & therefore I would expect the RTX 3060 to as well.

But your i5-11400 supports Intel Quick Sync which I presume is similar to GPU accelerated decoding so you might not need the 3060:

The Tiger Lake (microprocessor), Rocket Lake, Alder Lake & Raptor Lake adds VP9 12-bit & 12-bit 4:4:4 hardware decoding and HEVC 12-bit 4:2:0, 4:2:2 and 4:4:4 hardware decoding.[18] Gen12 Xe will also support native AV1 decode, which includes 10-bit 4:2:0 16K stills and 10-bit 4:2:0 8K, 4K and 2K video.[19]

High bitrate 4k60 HDR demo clips for testing: http://hdr4k.blogspot.com/

Ctrl+J doesn't appear to indicate whether GPU accelerated decoding is active, but in MPC-HC it will have "[H/W]" in the status if active, and LAV Video decoder properties shows if it's active.

[clsid]

Never ever use QuickSync. It is old and deprecated. Use DXVA2 or D3D11.

[flossy_cake]

Never ever use QuickSync. It is old and deprecated. Use DXVA2 or D3D11.

Ah ok, I thought Quick Sync was just Intel's branding to signify support for hardware acceleration. Didn't realise it was an actual API.

The device driver provides one or more interfaces, for example VDPAU, Video Acceleration API (VA API) or DXVA for video decoding, and OpenMAX IL or VA API for video encoding. One of these interfaces is then used by end-user software, for example VLC media player or GStreamer, to access the Quick Sync Video hardware and make use of it.

In LAV Video decoder dropdown list it has Quick Sync as a selectable option alternative to DXVA, so I guess there is a Quick Sync API as well.

In any case, if the CPU says it supports Quick Sync then it probably supports the DXVA API by the looks of it?

[huhn]

as he said use dxva2 or d3d11 instead.

[flossy_cake]

as he said use dxva2 or d3d11 instead.

Yeah, I never actually advised him to use Quick Sync, I only said his CPU supports Quick Sync. From what I can tell, Quick Sync support implies DXVA support, but I'm not 100% sure on that.

I use "DXVA2 copy-back" on my 1070 and can't seem to fault it. Did some screenshots to see if colours were different and they weren't, but I suppose there's the odd chance of some codec that doesn't play nice. I know Kodi's media player screws up the DXVA2 decoding and the tone mapping is all wrong, on my system at least.

[Sunspark]

I like Quick Sync at the moment because I feel that it is still performant and has slightly better colours, it might be gamma since it's mostly black shades I am noticing it on. Granted, I have to be able to prove this judgement instead of subjective feel.

That said, from a technical standpoint there is a physical difference between the two if this comment is accurate: "The important difference between something like QSV/NVDEC and DXVA/D3D11VA is that QSV & NVDEC use an ASIC on the GPU to do the decoding while DXVA & D3D11VA use the CPU and offload certain tasks like DCTs to the GPU."

Old machines might still be well-served by QSV since ASICs are what bitcoin miners use for speed.

ASIC=Application-specific integrated circuit. DCT=Discrete cosine transforms.

[huhn]

if it looks different it may finally been broken.
hardware decoder is known to be bit perfect.
That said, from a technical standpoint there is a physical difference between the two if this comment is accurate: "The important difference between something like QSV/NVDEC and DXVA/D3D11VA is that QSV & NVDEC use an ASIC on the GPU to do the decoding while DXVA & D3D11VA use the CPU and offload certain tasks like DCTs to the GPU."
wrong. there are hybrid decoder but the absolute majority of DXVA and D3d11 decoder (they are the same) are fully hardware decoded the CPU doesn't do anything they are asic.

where it is hard to proof it would be utterly insane to add 2 different asic on a GPU that do 100 % the same.
you can bet on that nvdec and d3d11 use the same ASIC same for quicklsync.

[clsid]

QuickSync uses the same exact fucking hardware decoder as DXVA. Same for NVDEC/CUVID and any other vendor specific wrapper.

Quality is also identical between all. If you see any difference, it is likely due to crappy post-processing that Intel driver likes to do. Start by disabling "Contrast Enhancement" in the Intel settings.

The QuickSync decoder implementation in LAV does not even support HEVC and VP9, so you might have actually been using software decoding for most of your files.

[Sunspark]

Following the links huhn posted of chroma upscaling https://forum.doom9.org/showthread.php?p=1967409#post1967409, I wished to contribute DXVA2 ones from my Intel HD Graphics 6000. Two sources are used here, and it is assumed that neither is the one that was used in the links huhn shared. Both sources are 10 bit and presented in D3D9 Exclusive. Decoding is being done by software due to the 10 bit.

4:2:0 source, chroma upscaling only to 4:4:4, no image scaling. Bicubic 60 AR. Honestly, this looks pretty good, I cannot complain.

https://dl.dropboxusercontent.com/s/ltglm7srsq0fpmv/420%20Bicubic60%20AR.png

4:2:0 source, DXVA2 chroma & image upscaling both as we cannot select DXVA2 as a chroma scaling option by itself, it must be bundled with image scaling.

https://dl.dropboxusercontent.com/s/c90qa4t9pvu6621/420%20DXVA2%20P010.png

4:4:4 source (this one, I have no idea if 4:4:4 sources actually exist, or if someone upscaled the chroma themselves and then put it out) DXVA2 chroma & image upscaling both.

https://dl.dropboxusercontent.com/s/41q4j1ccecww7il/444%20DXVA2%20YUV10.png

The DXVA2 image from the 4:2:0 source looks a little gritty for some reason. In actuality, you don't see the grit at all in motion unless you're looking for it. The 4:4:4 source doesn't have the grit at all, just a bit blurred.

[huhn]

knock yourself out: https://drive.google.com/file/d/12YUZbkUqkCGHcU25Ri_bCV0P5PaliDDU/view

[Balling]

Never ever use QuickSync. It is old and deprecated. Use DXVA2 or D3D11.

Actually qsvenc and qsvdec are state of the art just like nvenc and hwaccel nvdec. WTF. https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvdec.c

Qsvenc already supports SCC type of HEVC, no one else does, except reference encoder.

[Balling]

4:4:4 source (this one, I have no idea if 4:4:4 sources actually exist, or if someone upscaled the chroma themselves and then put it out)

Are you asking whether yuv444p10 bit pixel format exist? Well, dah, it does! Of course you need for example Y410 to have all the needed 30 bits (it is actually 32 bits, so 2 bits are alpha).

[clsid]

You need to fucking learn to read. He asked if a 4:4:4 source of that video existed.

My comment about QuickSync is about the only instance of QuickSync that is relevant to madVR and that is the implementation available in LAV Video Decoder.

You already made FFmpeg Trac a mess with all your ramblings. Please don't kill this forum as well.

[Sunspark]

Are you asking whether yuv444p10 bit pixel format exist? Well, dah, it does! Of course you need for example Y410 to have all the needed 30 bits (it is actually 32 bits, so 2 bits are alpha).

Well, of the two test files I tried, one of them is literally 4:4:4 out of the box and Y410. I found that very unusual because blurays even in UHD format are still 4:2:0. So this must have been something someone upscaled themselves and then put out in that way. It was interesting to compare the two though. One was the standard 4:2:0 which is what I wanted to test, and the other one was a curiosity. Both were 1080p resolution.

[x7007]

does anyone get 10bit in full windowed with windows 11 with madVRhdrMeasure159? everything else works but not this 19bit. and with 0.92.7 everything stopped working like bitrate 1bit or any other number and changing the black level doesn't do anything to the image.

@madshi, can you tell us how to fix the 10bit with windows 11??

[Sunspark]

I have an image quality and performance tip which is new for me and works well with h264 10-bit anime for those using DXVA2 scaling on older computers or igpu laptops.

I was reading a MadVR bug report which clued me in that a sub-optimal presentation exists with default settings for this type of file in LAV+MadVR.

On the video decoder settings 4:2:0 row, if P010 is checked, "Rendering" will show up on the madvr HUD and CPU fans will go to max and gpu load is higher than the following two.

If P010 is unchecked, it will play in P016, "Rendering" stat will not appear, and cpu fans will not max out.

If both P010 and P016 are unchecked, same as above, and it will play in 8-bit NV12 instead. GPU load is the same as with P016 but CPU usage is lower and fan speed is a bit lower as a result.

IMAGE QUALITY IS DAMAGED IN P010 MODE!

Notice the difference between the 3 below. NV12 & P016 are fine, P010 is gritty/lower-resolution.

Conclusion, if your display is 8-bit or lower use NV12 for the lowest cpu usage and ok scaling.

If your display is 10-bit or higher, then perhaps use P016 for a bit more cpu usage but it is unlikely you will notice the difference on anime at all, so NV12 is probably still a better recommendation.

https://dl.dropboxusercontent.com/s/ol6djts7jz2fcz0/dxva%20NV12.png

https://dl.dropboxusercontent.com/s/ne6p00ym04qldh8/dxva%20P010.png

https://dl.dropboxusercontent.com/s/gpk2uhqznpzrb2t/dxva%20P016.png
(https://dl.dropboxusercontent.com/s/gpk2uhqznpzrb2t/dxva%20P016.png)

[huhn]

please don't jump to conclusion.

first of all you are forcing DXVA this is not important for pretty much everyone there is a reason you should not sue it and you see the reason right now.

the next thing nv12 and p010 and such are not coupled to presentation bit deep or bit deep of the display.
BTW p010 and p016 are 100 % the same format if there is any issue than is your system not a general issue.

p010 to p016 conversation should be very very cheap on a CPU and GPUs.
converting p010 to NV12 should be very expensive on a CPU compare to the other conversation.

i linked you the same image i used to created the upscaled images.
just use EVR and make a screen shoot at native resolution it will use DXVA by default. mpcVR is also an option to take that screenshoot.

if the rendering stats disappear than this is a hint that madVR isn't even used for reasons so you have to investigated into that first.

and PLEASE don't talk about pixelformats with balling.
a file is not a pixel format it >can< be decoded to a pixelformat.
madVR supports all pixel format lavfilter can output(at least to my knowledge). lavfilter is able to create/decode or even convert files to pixel formats from 8 bit 4:2:0 to 16 bit RGB and everything in 8 10 and 16 bit inbetween we need to care in the video world.

[Sunspark]

first of all you are forcing DXVA this is not important for pretty much everyone there is a reason you should not sue it and you see the reason right now.

Yes, this is correct. I am using it, because my PC is a dual-core cpu with no discrete graphics card. I am able to run a bunch of the higher end stuff on it and they work, but the issue is that doing so causes the fans to go to 8000 rpm. So for that reason, I started exploring what methods/algos will allow "good enough" image quality without causing the fans to spin up.

I know everyone here has a RTX3090, etc. but sometimes it's worth considering everyone else. Madshi did say years ago he would like his software to be usable on lower-end systems too.

the next thing nv12 and p010 and such are not coupled to presentation bit deep or bit deep of the display. BTW p010 and p016 are 100 % the same format if there is any issue than is your system not a general issue.

Agreed, however the issue here, and this was mentioned in the bug report link below is that certain configurations seem to work better than others and this is qualitatively provable. The bug report was performance focused, but I was also able to identify a chroma image quality issue, that P010 is badly degraded, and that the solution is to use either P016 or NV12 to avoid the image degradation.

http://bugs.madshi.net/view.php?id=604

p010 to p016 conversation should be very very cheap on a CPU and GPUs. converting p010 to NV12 should be very expensive on a CPU compare to the other conversation.

That's interesting. For me and the bug report author, it was the other way around. The cheapest conversion was P010->NV12 followed by P010->P016. The most expensive result was to leave it at 10 on input and output.

i linked you the same image i used to created the upscaled images.
just use EVR and make a screen shoot at native resolution it will use DXVA by default. mpcVR is also an option to take that screenshoot.


I was using mpc-hc to take the screenshot. I am able to take it at both native resolution and scaled, but I am usually scaling to avoid black borders where possible.

if the rendering stats disappear than this is a hint that madVR isn't even used for reasons so you have to investigated into that first.

No, that's other pipeline stuff too.. for example, usage of an external subtitle filter can cause "rendering" to appear in the hud with corresponding increased time/power usage. Use of the internal subtitle renderer doesn't have that appear, etc. Rendering will appear if I use backbuffer presentation in a window, but it will disappear if I use frames in advance in fullscreen. It just depends, but not having it appear if possible to do so is certainly preferable because it's an indicator that something is absorbing cpu.

and PLEASE don't talk about pixelformats with balling.
a file is not a pixel format it >can< be decoded to a pixelformat.
madVR supports all pixel format lavfilter can output(at least to my knowledge). lavfilter is able to create/decode or even convert files to pixel formats from 8 bit 4:2:0 to 16 bit RGB and everything in 8 10 and 16 bit inbetween we need to care in the video world.

I didn't understand what you meant by balling, but I get the rest.

I wasn't challenging that madvr and/or lav couldn't create or support all formats, they do, I was saying there are numerical measurements and visual evidence that certain configurations function better than others, specifically where DXVA scaling is concerned if the source file is starting out as a 10-bit format.

It just works better to deselect P010 decoding in LAV (done in software not hardware in this instance) to be rendered by MadVR if you're using DXVA scaling. Less CPU usage, and better image quality.

The results are different if you are using a software algorithm for the scaling instead of DXVA.

[Balling]

Well, of the two test files I tried, one of them is literally 4:4:4 out of the box and Y410. I found that very unusual because blurays even in UHD format are still 4:2:0. So this must have been something someone upscaled themselves and then put out in that way. It was interesting to compare the two though. One was the standard 4:2:0 which is what I wanted to test, and the other one was a curiosity. Both were 1080p resolution.

No, there are native 444 10 bit encoded from RGB 64 bit png, and of course there are 444 16 bit files too that require Y416. Both are supported by madvr. I have both samples. This Y416 is used by Intel. Nvidia uses Pxxx just like Apple.

NV12 is 8 bit for Y, 4 bit for Cb, Cr together. It makes any quality 420 8 bit. For a very long time ffmpeg was using NV12 for 420 10 bit too, yet that requires more (P010, minimal optimal). For that and more bits (12) and 444 it was finally fixed here: https://github.com/FFmpeg/FFmpeg/commit/81147b5596ea19f7c5c153f4a534e9314d291fd3

>a file is not a pixel format it >can< be decoded to a pixelformat.

Total BS. A file requires some minimal pixel format. Wow. The fact that there are so many bugs in p016 and p010 is not a reason to say this disgusting BS. P016 was only fixed in ffmpeg in January. https://github.com/FFmpeg/FFmpeg/commit/da92865b270c1890a163d653393e682e3b431756

By Balling he meant me, it is my user name.

[huhn]

Yes, this is correct. I am using it, because my PC is a dual-core cpu with no discrete graphics card. I am able to run a bunch of the higher end stuff on it and they work, but the issue is that doing so causes the fans to go to 8000 rpm. So for that reason, I started exploring what methods/algos will allow "good enough" image quality without causing the fans to spin up.
it not an issue that you check these things it's your conclusion you are making.
first of all you are using DXVA2 processing which is know to be buggy ask an AMD user...

I know everyone here has a RTX3090, etc. but sometimes it's worth considering everyone else. Madshi did say years ago he would like his software to be usable on lower-end systems too.

they clearly don't and that's not the issue

Agreed, however the issue here, and this was mentioned in the bug report link below is that certain configurations seem to work better than others and this is qualitatively provable. The bug report was performance focused, but I was also able to identify a chroma image quality issue, that P010 is badly degraded, and that the solution is to use either P016 or NV12 to avoid the image degradation.
this is the issue you talk about an issue with p010. p010 is not the issue it's your system/GPU driver.
you just test one system with one implementation and point your finger at p010.

That's interesting. For me and the bug report author, it was the other way around. The cheapest conversion was P010->NV12 followed by P010->P016. The most expensive result was to leave it at 10 on input and output.
and does it make any sense to you that doing nothing is the most expensive? while doing something is cheaper. not here to point at the bug report to say it is wrong or something just saying there is more going on.


I was using mpc-hc to take the screenshot. I am able to take it at both native resolution and scaled, but I am usually scaling to avoid black borders where possible.
if you want to compare intel DXVA chroma scaling i need a native resolution image of the 1 frame encode i shared else i can't compare it to the other scaler.


No, that's other pipeline stuff too.. for example, usage of an external subtitle filter can cause "rendering" to appear in the hud with corresponding increased time/power usage. Use of the internal subtitle renderer doesn't have that appear, etc. Rendering will appear if I use backbuffer presentation in a window, but it will disappear if I use frames in advance in fullscreen. It just depends, but not having it appear if possible to do so is certainly preferable because it's an indicator that something is absorbing cpu.


back buffer subtitles CPU?
i know all what that means you slow don't a bit the backbufffer doesn't care about the CPU the presentation in advanced doesn't care about the CPU presenation doesn'T care about the CPU in general. subtitles clearly care about the CPU.
I didn't understand what you meant by balling, but I get the rest.
soon you will.

I wasn't challenging that madvr and/or lav couldn't create or support all formats, they do, I was saying there are numerical measurements and visual evidence that certain configurations function better than others, specifically where DXVA scaling is concerned if the source file is starting out as a 10-bit format.

It just works better to deselect P010 decoding in LAV (done in software not hardware in this instance) to be rendered by MadVR if you're using DXVA scaling. Less CPU usage, and better image quality.
on your specific setup that's important.
here are my results.
https://abload.de/img/amdd3d11chromascalingzzker.png
https://abload.de/img/amddxva2chromascalingq2k44.png

RX5700 XT driver 30.0.21000.22018
this information is important in this instances because with DXVA and D3d11 processing it can drastically change between version.

Total BS. A file requires some minimal pixel format. Wow. The fact that there are so many bugs in p016 and p010 is not a reason to say this disgusting BS. P016 was only fixed in ffmpeg in Januray. https://github.com/FFmpeg/FFmpeg/com...3e682e3b431756
ohh yeah a h265 stream is a pixel format yes? cool...

[Balling]

>ohh yeah a h265 stream is a pixel format yes? cool...

Yes, indeed it compresses some pixel format and renders to some minimal pixel format that then goes to swapchain, that defines primaries and transfer, though it can directly render YCbCr to the display, not convert to RGB. I am sure you know all that, though then again you do not develop MPC-BE that recently added hacked *_Intel decoders that support 12 bit 444 Rext, but MPC-HC!

[nevcairiel]

and does it make any sense to you that doing nothing is the most expensive? while doing something is cheaper. not here to point at the bug report to say it is wrong or something just saying there is more going on.


It actually makes sense that converting P010 to NV12 is faster, because it reduces the memory bandwidth requirements, and the conversion itself is very cheap (of course you lose precision, which is not ideal, even with dithering applied)
P010 to P016 is basically not even a conversion, its just a rename, so I would expect it to be roughly equal to P010 output, at least on the decoders end, no insight in what madVR might do.

[huhn]

here we go again.
the H265 encoder may take a pixel format but the output of it the >file< is a h265 bitstream (i call it a bitstream here if you want to know the correct term feel free to google it but what so ever it's not a pixelformat) because the bitstream is pretty boring it needs a decoder and this things turns the bitstream into something else that can be used like a pixel format and here is the point if the decoder wants to it can output it in nv12 or yv12 it can choice.

but h265 is now a renderer and it can render directly to a presentation surface and it does not convert to RGB in a madVR thread. wow...

[Sunspark]

on your specific setup that's important.
here are my results.
https://abload.de/img/amdd3d11chromascalingzzker.png
https://abload.de/img/amddxva2chromascalingq2k44.png

RX5700 XT driver 30.0.21000.22018
this information is important in this instances because with DXVA and D3d11 processing it can drastically change between version.

If you deselect P010 output format in lav video decoder settings, the dxva2 output will look like the d3d11 output.

[huhn]

that just breaks d3d11 and d3d9 is just like d3d11 before which is a really bad result
ffmpeg.exe -r 60 -vcodec rawvideo -f rawvideo -s 1920x1080 -pix_fmt yuv420p10le -stream_loop 5 -i "C:\Users\might\OneDrive\Desktop\RawScreenshots\1\screenshots.yuv420p10le" -c:v libx264 -crf 16 -r 60 "test.mkv"
pause
why did i do it like this... it's been a while what ever.

[Balling]

here we go again.
the H265 encoder may take a pixel format but the output of it the >file< is a h265 bitstream (i call it a bitstream here if you want to know the correct term feel free to google it but what so ever it's not a pixelformat) because the bitstream is pretty boring it needs a decoder and this things turns the bitstream into something else that can be used like a pixel format and here is the point if the decoder wants to it can output it in nv12 or yv12 it can choice.

but h265 is now a renderer and it can render directly to a presentation surface and it does not convert to RGB in a madVR thread. wow...

It is called annex b, I think I know more about it than you do. You cannot convert to RGB, because what is encoded in HEVC is YCbCr, not directly RGB, though it can be encoded too. Or in lossless mode YCgCo-R is used internally to preserve losslessly stuff. Sigh. Wow. You cannot somehow convert to R'G'B', before decoding is YCbCr. Seriously.

[Balling]

that just breaks d3d11 and d3d9 is just like d3d11 before which is a really bad result
ffmpeg.exe -r 60 -vcodec rawvideo -f rawvideo -s 1920x1080 -pix_fmt yuv420p10le -stream_loop 5 -i "C:\Users\might\OneDrive\Desktop\RawScreenshots\1\screenshots.yuv420p10le" -c:v libx264 -crf 16 -r 60 "test.mkv"
pause
why did i do it like this... it's been a while what ever.

yuv420p10 is not RAW, real RAW is Bayer sensor data (it is RGGB, so RGB), not YCbCr. You did not tag output either s BT.2020 nc matrix? Whatever is in .yuv file (the correct name .yuv not what you did here, wow)

[huhn]

It is called annex b, I think I know more about it than you do. You cannot convert to RGB, because what is encoded in HEVC is YCbCr, not directly RGB, though it can be encoded too. Or in lossless mode YCgCo-R is used internally to preserve losslessly stuff. Sigh. Wow. You cannot somehow convert to R'G'B', before decoding YCbCr. Seriously.

this is the madVR thread madVR can only render RGB and windows really doesn't like YCbCr rendering what ever read into it what you want.
h265 is h265 the decoded image which is not h265 anymore is usually a type of YUV get the difference please.
and you are claiming to render h265 by using h265 as a renderer not me.
yuv420p10 is not RAW, real RAW is Bayer sensor data (it is RGGB, so RGB), not YCbCr.
my mistake the FFMPEG cmd must be wrong then go correct it and leave me alone.
ffmpeg would never mean uncompressed or not encoded with raw.
let's take the CGI image here and take it with a camera so we have to debayer it so it is raw enough for you...

[huhn]

It actually makes sense that converting P010 to NV12 is faster, because it reduces the memory bandwidth requirements, and the conversion itself is very cheap (of course you lose precision, which is not ideal, even with dithering applied)
P010 to P016 is basically not even a conversion, its just a rename, so I would expect it to be roughly equal to P010 output, at least on the decoders end, no insight in what madVR might do.

correct that's why a different implementation should be checked too to see what happens.

[Balling]

It actually makes sense that converting P010 to NV12 is faster, because it reduces the memory bandwidth requirements, and the conversion itself is very cheap (of course you lose precision, which is not ideal, even with dithering applied)
P010 to P016 is basically not even a conversion, its just a rename, so I would expect it to be roughly equal to P010 output, at least on the decoders end, no insight in what madVR might do.

First part is correct, except ffmpeg (nvidia develeopers patches) removed this insanity, because you are never supposed to do that. Second part IS ABSOLUTELY wrong. For a long time p010 was the same as p016 because NVIDIA WAS INCAPABLE TO IMPLEMENT PROPER SUPPORT IN FFMPEG. Only when Apple added new P210/P410/P216/P416 (every one little and big endian), etc, formats one genius (rcombs) implemeneted it all, since he is an Apple fanatic or something, yet it took him insane amount of time to get it all correctly.

See all 50 or so commits here https://github.com/FFmpeg/FFmpeg/commits?author=rcombs starting with https://github.com/FFmpeg/FFmpeg/commit/88d804b7ffa20caab2e8e2809da974c41f7fd8fc and see how many commits above helped to fix this.

And now remember that all internal to qsv pixel formats are slightly different, that is what Y416 is. And they need to be mapped.

[nevcairiel]

First part is correct, except ffmpeg (nvidia develeopers patches) removed this insanity, because you are never supposed to do that. Second part IS ABSOLUTELY wrong. For a long time p010 was the same as p016 because NVIDIA WAS INCAPABLE TO IMPLEMENT PROPER SUPPORT IN FFMPEG. Only when Apple added new P210/P410/P216/P416 (every one little and big endian), etc, formats one genius (rcombs) implemeneted it all, since he is an Apple fanatic or something, yet it took him insane amount of time to get it all correctly.

See all 50 or so commits here https://github.com/FFmpeg/FFmpeg/commits?author=rcombs starting with https://github.com/FFmpeg/FFmpeg/commit/88d804b7ffa20caab2e8e2809da974c41f7fd8fc and see how many commits above helped to fix this.

And now remember that all internal to qsv pixel formats are slightly different, that is what Y416 is. And they need to be mapped.

As usual, you have no idea what you are talking about. Please just stay out of these forums. Nothing talked about here recently even interacted with ffmpeg at all. Your comments are wrong, out of context, and not wanted.

[Balling]

As usual, you have no idea what you are talking about. Please just stay out of these forums. Nothing talked about here recently even interacted with ffmpeg at all. Your comments are wrong, out of context, and not wanted.

Madvr already supports it all. As you can see from Prores 4444 XQ it shows Y416. Anyway, this is just hillarious considering MAX_SLICES needs to be increased to 256 to get correct decoding on d3d11va on some files, I do not see you submitting that on patchwork, only using that in your private fork. Who should stay out now? Wow. BTW, you can commit to at least some parts of ffmpeg directly, you could have fixed that. I think I am perfectly capable of thinking for myself, you and Paul B may just shut up. What is up with you blocking me on Lavfilters repo on Github and Paul B opening insane issues on trac trying to get me blocked? You americans become completely nuts.

[huhn]

i try it one more time "nice".

this is the madVR thread.
that means directshow hardware decoding on windows. video rendering and such. not ffmpeg...
we don't have prores hardware decoding and it does not matter here this is the madVR thread if someone writes a directshow filter that can decode it it doesn't matter here because if madVR can accept that or not is irrelevant because it will except everything you put in a pixel format that is supports it's irrelevant what it was before this also counts for codecs not even written yet.

it's kinda scarry that you even bring it up. you just bring up random topic completely unrelated to this thread.

[Sunspark]

that just breaks d3d11 and d3d9 is just like d3d11 before which is a really bad result
ffmpeg.exe -r 60 -vcodec rawvideo -f rawvideo -s 1920x1080 -pix_fmt yuv420p10le -stream_loop 5 -i "C:\Users\might\OneDrive\Desktop\RawScreenshots\1\screenshots.yuv420p10le" -c:v libx264 -crf 16 -r 60 "test.mkv"
pause
why did i do it like this... it's been a while what ever.

Hi, this is good because it really points to how configurations can be very situational and one forgets about the other setups if they aren't the best fit for their own equipment.

I'll give examples.

In the Chrome browser, it is possible in the flags to select which ANGLE rendering method you wish to use, whether OpenGL, D3D9, D3D11 or D3D11on12. I benchmarked each of these in a 3D environment through the browser, and the best performance on my GPU was held with D3D11.

With MadVR however, much of it was written for D3D9 as I understand it, and my GPU has lower CPU & GPU requirements when I follow the D3D9 codepath in the renderer rather than the D3D11 one. I did test D3D11 several times to establish that all functions were working, but it isn't as performant. The D3D9 path is more performant on my GPU and I believe it is renderer specific, because as an example the Microsoft Films & TV/Movies & TV video player app uses D3D11 but has a lower system load so that tells me it is more optimized for that API.

My conclusion here is that with this renderer if one has a good GPU then the lack of D3D11 optimization isn't a big deal since there is horsepower to spare, but on older systems it is more optimal to run in D3D9 presentation mode instead and to uncheck P010 output.

I do have "Disable full-screen optimisations" checked for the MPC players so Windows doesn't mess with things too much.

I think I have everything tuned as good as it's going to get, the only thing that would make it lower would be to use a different renderer, but I am so used to MadVR because I have it dialed in. I tried EVR-CP a couple times but it didn't feel as smooth. I cannot use just EVR because I need subtitles. MPC-VR is an option to explore for later that I haven't really looked at much at all but it's good that another option exists.

[clsid]

As mentioned by nevcairiel already, the reason that unchecking P010 helps with performance for you, is that the size of the decoded video data gets reduced by a factor two. So only half the amount of data needs to be copied from CPU memory to GPU memory. This can help to avoid bottlenecks with PCI bandwidth, and also reduces CPU/GPU usage.

If you are using DXVA2 for video decoding, then you should try D3D11 decoding in combination with D3D11 rendering in MadVR. That should give even better performance.

[Sunspark]

As mentioned by nevcairiel already, the reason that unchecking P010 helps with performance for you, is that the size of the decoded video data gets reduced by a factor two. So only half the amount of data needs to be copied from CPU memory to GPU memory. This can help to avoid bottlenecks with PCI bandwidth, and also reduces CPU/GPU usage.

If you are using DXVA2 for video decoding, then you should try D3D11 decoding in combination with D3D11 rendering in MadVR. That should give even better performance.

The Valvrave file doesn't permit hardware decoding at all. However, I can flip the D3D11 presentation checkbox on. The below four results are all in avcodec software fallback decoding mode. Hardware scaling is permitted.

D3D11 exclusive (8 bit)
h264, 10 bit, 4:2:0 -> P016, 16 bit, 4:2:0
chroma > DXVA
image > DXVA
average stats
dxva 1.39ms
rendering 3.04ms
present 0.28ms

D3D11 exclusive (8 bit)
h264, 10 bit, 4:2:0 -> P010, 10 bit, 4:2:0
chroma > DXVA
image > DXVA
average stats
dxva 0.81ms
rendering 3.71ms
present 0.29ms

D3D9 exclusive (new path)
h264, 10 bit, 4:2:0 -> P010, 10 bit, 4:2:0
chroma > DXVA
image > DXVA
average stats
dxva 0.11ms
rendering 3.21ms
present 0.14ms

"rendering" disappears below once flipped to P016.

D3D9 exclusive (new path)
h264, 10 bit, 4:2:0 -> P016, 16 bit, 4:2:0
chroma > DXVA
image > DXVA
average stats
dxva 0.15ms
present 0.18ms

Below is with a regular file that can support hardware decoding.

DXVA scaling is not allowed with this decoding/presentation mode when D3D11 hardware decoding is active, so it falls back to software scaling.

D3D11 exclusive (8 bit)
h264, 8 bit, 4:2:0 -> NV12, 8 bit, 4:2:0 (DXVA11)
chroma > Bicubic60 AR
image > Bilinear
average stats
rendering 6.96ms
present 0.51ms

Another bug I found is that with the last file used, DXVA scaling is permitted with D3D11 windowed mode but not exclusive mode.

D3D11 fullscreen windowed (8 bit)
h264, 8 bit, 4:2:0 -> NV12, 8 bit, 4:2:0 (DXVA2)
chroma > DXVA
image > DXVA
average stats
dxva 2.65ms
rendering 8.19ms
present 0.40ms

And here is the same file as above, hardware decoding is active and hardware scaling is active in the D3D9 path.

D3D9 exclusive (new path)
h264, 8 bit, 4:2:0 -> NV12, 8 bit, 4:2:0
chroma > DXVA
image > DXVA
average stats
dxva 0.39ms
present 0.45ms

The GPU is an integrated Intel HD Graphics 6000.

I believe both files and both D3D paths (whether decoding or presentation) demonstrate that with the LAV & MadVR pairing together, that the D3D9 path is the best one for this GPU and that P010 should be avoided in favour of P016 (performance and image quality reasons both).

[huhn]

madVR doesn't have a D3D11 path it just doing instantly an interop when d3d11 decoding is done(this is not free) and it's also doing an interop when d3d11 presentation is done again this is not free.

feel free to test mpcVR which has native d3d11 and d3d9 paths.
i don't have a GPU slow enough ot register a notable difference.

nv12 and p010 is a trade of i did not except that that dithering can be this free/cheap (it cost quite a lot in madVR). you trade the conversation cost with the upload cost if you are bandwidth limited this seems to help alot.

maybe there is a point for nv15. no point in talking about this here because it's very unlikely to happen with madVR.

[Sunspark]

I will try mpcvr later on so I can get a second set of comparison numbers to see what entirely different code looks like.

[clsid]

Yes, MPCVR would be more suitable for you since you don't use the advanced scalers in MadVR. One downside is that MPCVR only has basic HDR tonemapping. But it does offer HDR passthough.

[Sunspark]

2 Minutes Average. LAV 75 was used as the decoder for MPC-VR and LAV 76 was used as the decoder for MadVR. MadVR settings are already the most optimal copy-back settings. MPCVR was using only DXVA2/DX11, no shaders. MPC's video decoder was not tested here because I was focusing on the video renderer performance with the assumption that there wouldn't be much if any difference between LAV and MPC for video decoding. Both setups were using the MPC audio decoder. Intel HD Graphics 6000 integrated GPU. RPM, CPU and GPU were all collected using HWiNFO64.

< Valvrave (10-bit file, software decoding only) >

MadVR D3D9 (Using P016)
5791 RPM
25.2% Total CPU Usage
12.3% GPU D3D Usage

MPCVR D3D9 (Using P010, P016 doesn't work)
3991 RPM
20% CPU
9.8% GPU

MPCVR D3D11
5676 RPM
22% CPU
15.2% GPU

For the above file, MPCVR D3D9 had the lowest fan rpm and system load.


< Picard (8-bit file, hardware decodable) >

[Software Decoding]

D3D9 MPCVR
3916 RPM
18.2% CPU
14% GPU

D3D11 MPCVR
3934 RPM
16.6% CPU
3.5% GPU

For this decoding method, fan speeds were the same. CPU was comparable but D3D11 GPU load was surprisingly significantly lower compared to D3D9. The only instance where D3D11 did better in a bracket.

[DXVA2 Copy-back]

D3D9 MPCVR
3928 RPM
8.5% CPU
3.7% GPU

D3D11 MPCVR
3942 RPM
12.5% CPU
15.5% GPU

For this decoding method, fan speeds were the same and D3D9 was faster.

[Lav QuickSync]

MadVR D3D9
3865 RPM
14.9% CPU
11.4% GPU

D3D9 MPCVR
3894 RPM
9.6% CPU
3.7% GPU

D3D11 MPCVR
3884 RPM
15.4% CPU
14.8% GPU

For this decoding method, fan speeds were the same for all three. D3D9 MPCVR had the lowest system load.

[Lav DXVA2 (native)]

D3D9 MPCVR
3874 RPM
4.2% CPU
3.4% GPU

D3D11 MPCVR
3941 RPM
11.8% CPU
8.7% GPU

For this decoding method, fan speeds were the same, but system load was more than half when rendered in D3D9.

[Lav D3D11 Decoding]

D3D9 MPCVR
3932 RPM
7.9% CPU
6.4% GPU

D3D11 MPCVR
3998 RPM
8.3% CPU
13.8% GPU

For this decoding method, fan speeds were the same and system load was lower for D3D9 compared to D3D11. System load was higher for D3D9 VR when D3D11 decoded compared to DXVA2 (native) decoding. D3D11 VR was somewhat the same between dvxa2-native and d3d11.

Of the 2 copy-back decoders, they were basically the same in D3D9 mode though MPCVR had a lower system load than MadVR. Both D3D9 copy-back methods were faster than the software decoded D3D11 which was faster than software decoded D3D9.

Of the 2 native decoders, DXVA2 (native) presented in D3D9 MPCVR was by a notable margin the fastest between the native decoders and the fastest overall of all options.

Image quality was not evaluated here though it is known that MadVR needs to use software or copy-back decoding for IQ. It is not known to me if MPCVR handles copy-back differently than native where IQ for chroma, etc. is concerned.