madVR - high quality video renderer (GPU assisted) [Archive] - Page 1197

zorr

23rd July 2020, 21:04

The metrics used are:

- PSNR
- SSIM
- IFC
- PI
- SIS

PSNR and SSIM are well known. IFC (http://users.ece.utexas.edu/~gustavo/papers/de%20Veciana1251902020.pdf) (Information Fidelity Criterion) is a metric based on natural scene statistics that has been shown to have a high correlation with perceptual scores in the context of SR evaluation. PI (https://arxiv.org/pdf/1809.07517.pdf) (Perceptual Index) is a No Reference metric designed for the 2018 PIRM Challenge on Perceptual Image Super-resolution, which is also highly correlated with the ratings of human observers in a human-opinion study. SIS (https://core.ac.uk/download/pdf/187752279.pdf) is a method specifically designed for assessing the visual quality of super-resolved images, which also has a very high correlation with a human-opinion study carried out with a database built for the same purpose.

Can I ask what software you used to calculate all those metrics?

Alexkral

23rd July 2020, 21:43

Can I ask what software you used to calculate all those metrics?

Matlab

- IFC (https://live.ece.utexas.edu/research/Quality/index_algorithms.htm) (the link is at the bottom)
- PI (https://github.com/roimehrez/PIRM2018)
- SIS (https://github.com/weiyiferonia/SR-IQA)

huhn

24th July 2020, 12:27

Considering the tests above, can someone please explain why everyone is advising NGU AA for chroma upscaling?

these are just metrics that are sadly not represent of how the human eye judges images. that doesn't mean they are useless.
NGU AA moves an image by half a subpixel so do you need to move chroma it's not that simple but it should give you an idea.

the next and most important point is where NGU sharp is strong at sharp error free images that's simply not the case for chroma which is usually soft for the most part.

chros

25th July 2020, 00:19

As you can see, the NGU scores are completely ordered (Sharp > Standard > Anti-Alias > Soft) especially in terms of PSNR and SSIM, with some differences in the other metrics (e.g. AA low performs better than AA med for three metrics).
This is what we saw in Joao's test (https://artoriuz.github.io/blog/mpv_upscaling.html) as well (with couple of differences, though he used different metrics), but we didn't know how the different strengths compare to each other.
Now we do, and it's shocking! :)
Even NGU Sharp Low is better than NGU Standard Very High (except for IFC metrics)!
Meaning the strength is less important than the actual algo that is used.

This correlates with madshi's recent statements (https://www.avsforum.com/forum/37-video-processors/3053602-madvr-envy-anticipation-thread-85.html#post59790074) (and here (https://www.avsforum.com/forum/37-video-processors/3053602-madvr-envy-anticipation-thread-82.html#post59690218)) about this:
- "frankly, the difference between some of the highest algo quality levels is minimal at best. For example, NGU Very High upscaling quality consumes 2.5x as much performance as NGU High upscaling quality, but with most movie frames there will be exactly zero image quality improvements. Maybe you'll find 1% improvement if you carefully search for that one rare ultra sharp video frame which has lots of thin diagonal or curved lines in it. But you *really* have to search for it."
- "It's interesting that you can see a noticeable difference between NGU Medium and High quality for chroma upscaling. Most users (probably including me) would have a hard time seeing a difference there."

Note that NGU AA is faster than the rest of the 3 NGU algos (Soft, Standard, Sharp) that are on the same GPU performance level at a given strength.

So, in summary, I don't see the point of using NGU Soft and Standard:
- with a clean source, no matter what the resolution is (1080p, 720p, 480p), NGU Sharp is the way to go for luma and chroma as well (High is already really high quality)
- with a fuzzy source NGU AA can be used to hide artifacts, but it's still questionable, since we can use other madvr algos for that

NGU Soft is consistently below Lanczos, same as AA for all metrics except PSNR and SSIM, and even Standard for IFC.
Yes, it's interesting to see that Lanczos is so good, just like in the other test (even better than ewa_lanczossharp (Jinc) and way faster). Although when he used an anime then Lanczos was slightly below of NGU Soft.

FSRCNNX_x2_8-0-4-1 performs better than the other FSRCNNX for all metrics except PSNR.
That's a strange result, in the other test it's always last out of the 3 expect for 1 case. But as we saw above the strength of a given algo is less important.
What more important is (as we saw in the other test as well) that it's in the same ballpark as NGU Sharp Med-High-VeryHigh (depending on the metric) and it's faster than them (https://forum.doom9.org/showthread.php?p=1907691#post1907691).

Waifu performs well
Yes, but unfortunately it's unusable for realtime playback. :) And since it was created for photo, who knows how it works with video.

and needless to say, I am very satisfied with the AiUpscale results. :)
Congrats, truly outstanding results! The photos look really good in the repo!

Couple of questions:
- did you automate the comparing process? If so, can you publish it as well (e.g. in your repo)?
- how do the performance of your shaders compare to the other algos?
- can you convert your algos into player (mpc-hs/be and mpv) supported shaders to be able to try them out?

nsnhd

25th July 2020, 03:11

That is very useful. I will reconfig my settings based on very high, high, med. Very high may be not necessary anymore.

shimarin

25th July 2020, 05:05

Note that NGU AA is faster than the rest of the 3 NGU algos (Soft, Standard, Sharp) that are on the same GPU performance level at a given strength.This isn't true in the brief testing I did. AA had higher GPU and power usage.

Alexkral

25th July 2020, 06:33

That's a strange result, in the other test it's always last out of the 3 expect for 1 case. But as we saw above the strength of a given algo is less important.
In this case I think it's important. I think the reason is that it's a little bit sharper, PSNR (and probably also the other metrics used in the other test) tends to prefer slightly oversmoothed images. This is not the case with the metrics designed for SR assessment. Anyway I think it is very well trained.

- did you automate the comparing process? If so, can you publish it as well (e.g. in your repo)?

For the NGU images, I made an AviSynth script (I had to add tags to the name to get the correct levels, primaries and matrix), disabled all madVR processing, opened the script with MPC-HC, made the necessary adjustments and captured the screen.
For the rest of the images (apart from Lanczos which is made with Matlab) I used the VirtualDub2 batch processing and AviSynth Batch Scripter (it can also be used to make VapourSynth scripts) with different templates for AiUpscale, FSRCNNX and VapourSynth-Waifu2x-caffe.
I couldn't find a way to save the images simply by their name with ImageWriter (I don't think it's possible), so the image names have added a percent or zero character.
I can upload the scripts and templates that I've used and also the images, but not the FSRCNNX implementation, that's another avsi, other shaders, etc. I prefer not to use Github at the moment for this, maybe I'll do a repo later.

So here are the scripts (https://drive.google.com/file/d/1svWjKUugWLqsIDVrEIKE5Qmni6-A_wHa/view?usp=sharing) and the images (https://drive.google.com/file/d/1GzvYqgc_BSapljrAhBfqEHatIpEYEAuf/view?usp=sharing).

- how do the performance of your shaders compare to the other algos?

You have some performance results in the first post of the AiUpscale thread here (https://forum.doom9.org/showthread.php?t=181665). I did the same with FSRCNNX and this is the result:

1080p -> 2160p

FSRCNNX_x2_8-0-4-1 = 33.51 fps
FSRCNNX_x2_16-0-4-1 = 25.00 fps
FSRCNNX_x2_56-16-4-1 = 17.84 fps

540p -> 1080p

FSRCNNX_x2_8-0-4-1 = 126.80 fps
FSRCNNX_x2_16-0-4-1 = 91.24 fps
FSRCNNX_x2_56-16-4-1 = 63.50 fps

For NGU you'll have to look at the rendering times, I'm not sure they can be translated to fps. And Waifu I don't know.

- can you convert your algos into player (mpc-hs/be and mpv) supported shaders to be able to try them out?
You can already use the mpv hooks of the Fast and Medium models, I have added them in a separate download. In MPC-HC/BE it's not possible because we would lose the chroma channels.

chros

25th July 2020, 23:17

That is very useful. I will reconfig my settings based on very high, high, med. Very high may be not necessary anymore.
Yes, exactly that's what I think, especially if you don't use huge screens with a projector but even then ... :)
There were (unfounded) statements in the past that suggested that NGU Sharp VeryHigh results in significant quality improvements, hence you need to have a really high-end GPU for madvr. As we see that's not the case.
Unless you already have one and don't mind the noise you can use NGU Sharp VeryHigh, otherwise NGU Sharp High-Med-Low for luma is fine as well.
As other blog article showed us, there's a slight jump in chroma quality when doubling (KrigBileteral) is used, so it's better to choose NGU Sharp Low-Mid(-High) for chroma instead of sacrificing it on the altar of NGU Sharp VeryHgh for luma.

As we stated multiple times, an old pascal underclocked/undervolted (!) nvidia gtx 1060 6GB using d3d11-native can do 1080p@23p -> 2160p NGU Sharp High for luma and NGU Sharp High + Low for chroma easily (leaving room for other image enhancements if needed).
And as we see how madvr development goes recently, probably there will be no need to replace it for a long time :)

This isn't true in the brief testing I did. AA had higher GPU and power usage.

What OS/GPU/mode do you use?
Here: Win10 / 1060 6GB / d3d11-native / 4k Oled
- using 2160p@23p content (only chroma (High) upscaling): NGU AA is slightly faster than NGU Sharp (~2-4% at 1569Mhz)
- using 1080p@23p content (luma (High) + chroma (High + Low) upscaling): NGU AA is slightly faster than NGU Sharp (~4-6% at 1569Mhz)

---

And since we are talking about NGU Sharp (High) upscaling, I made a unscientific (visual) real-world test (again) using 3 different flavours of the same content on 4k Oled: all of them are SDR web-dls from different service providers
- 2160p@23p: ~16Mbps (only chroma NGU Sharp High upscaling)
- 1080p@23p: ~10Mbps (luma NGU Sharp High and chroma NGU Sharp High + NGU Sharp Low upscaling)
- 1080p@23p: ~6Mbps (luma NGU Sharp High and chroma NGU Sharp High + NGU Sharp Low upscaling)

The result: 2160p > 1080p~10Mbps > 1080p~6Mbps

NGU can't do wonders if the source is crap (low bitrate), and there's even a clear visible difference between 2160p and the better 1080p as well (although the difference between bitrate is not huge).
Meaning, 4k resolution of the same content is better to choose than a 1080p version, no matter which NGU algo and strength is chosen.

chros

26th July 2020, 01:28

So here are the scripts (https://drive.google.com/file/d/1svWjKUugWLqsIDVrEIKE5Qmni6-A_wHa/view?usp=sharing) and the images (https://drive.google.com/file/d/1GzvYqgc_BSapljrAhBfqEHatIpEYEAuf/view?usp=sharing).
Thanks.

In this case I think it's important. I think the reason is that it's a little bit sharper, PSNR (and probably also the other metrics used in the other test) tends to prefer slightly oversmoothed images. This is not the case with the metrics designed for SR assessment. Anyway I think it is very well trained.
So, do you say that FSRCNNX_x2_8-0-4-1 is a bit sharper than the other 2 FSRCNNX versions?

You can already use the mpv hooks of the Fast and Medium models, I have added them in a separate download. In MPC-HC/BE it's not possible because we would lose the chroma channels.
Can you elaborate a bit more why that is? :o

You have some performance results in the first post of the AiUpscale thread here (https://forum.doom9.org/showthread.php?t=181665). I did the same with FSRCNNX and this is the result:

1080p -> 2160p

FSRCNNX_x2_8-0-4-1 = 33.51 fps
FSRCNNX_x2_16-0-4-1 = 25.00 fps
FSRCNNX_x2_56-16-4-1 = 17.84 fps

540p -> 1080p

FSRCNNX_x2_8-0-4-1 = 126.80 fps
FSRCNNX_x2_16-0-4-1 = 91.24 fps
FSRCNNX_x2_56-16-4-1 = 63.50 fps

For NGU you'll have to look at the rendering times, I'm not sure they can be translated to fps. And Waifu I don't know.

You can already use the mpv hooks of the Fast and Medium models, I have added them in a separate download.
Thanks, I haven't noticed them under releases.
I quickly checked them using 1080p@23p -> 2160p, using bicubic for chroma (no lanczos for NGU in madvr). I only tried 2x_Illustration variant of Fast and Medium (gpu-hq profile is used without debanding in mpv.net).
Performance results are like yours:
- FSRCNNX-8-0-4-1: is between NGU Sharp Low and Med !
- AiUpscale_Fast_2x_Illustration: ~NGU Sharp High
- FSRCNNX-16-0-4-1: in the middle of NGU Sharp High and VeryHigh
- FSRCNNX_x2_56-16-4-1: significantly slower than NGU Sharp VeryHigh
- AiUpscale_Medium_2x_Illustration: even slower than FSRCNNX_x2_56-16-4-1

So, AiUpscale Fast Illustration version is a pretty good alternative to NGU Sharp, at the performance level of NGU Sharp High and scoring higher in your test than NGU Sharp VeryHigh (except for PSNR) and even Waifu2x-caffe in 3 metrics out of 5! :)

Very good job, thank You!
I'll try to do some "blind" test later and I'll post about it in the mpv.net thread.

Alexkral

26th July 2020, 04:20

So, do you say that FSRCNNX_x2_8-0-4-1 is a bit sharper than the other 2 FSRCNNX versions?

Yes, look at the baboon image in full screen.

Can you elaborate a bit more why that is?

It's not the only reason. In MPC-HC the shaders process the video that's being rendered, here the chroma is discarded, multiple clips are used to store the information to scale the luma on their channels and process it, and then the chroma is rejoined with the scaled luma. So it's completely different.

So, AiUpscale Fast Illustration version is a pretty good alternative to NGU Sharp, at the performance level of NGU Sharp High and scoring higher in your test than NGU Sharp VeryHigh (except for PSNR) and even Waifu2x-caffe in 3 metrics out of 5! :)

Note that the models used in the test are the "Photo" models as they are best suited for most of the dataset content. The "Illustration" models are made for anime, drawings, etc.

Very good job, thank You!

I'm glad you find it useful. :)

Morku

28th July 2020, 17:29

Hi,

can I ask here what exactly the option General -> "use D3D11 for presentation" in madVR does? Not that it switches between D3D11 and D3D9 more like... what this presentation thing is in general.

https://i.imgur.com/WHiPSPM.png

The reason why I ask is, on one system I use, the videoplayback is getting frame drops/repeating frames when:

- the video is in fullscreen
- the moment when GUI or Overlay elements appear and disappear (like navigation bar or option bar (Alt))
- presentation switches this moment between "fullscreen windowed" and "windowed", even when it's just the navigation bar
- this 'change' makes the video choppy for a brief moment

If you care what it looks like, you can see here: https://www.dropbox.com/s/j0hnzx8sexb3qfc/choppy.mp4?dl=0

This does not just happen on MPC-HC with madVR, it also happen with the Netflix App when navigation bar is displayed or subtitles are displayed. Even the testvideo in Windows 10 settings -> Apps -> Video has the same issue when set to fullscreen and navigationbar is displayed in and out. So they use the same way of D3D presentation...?

The issue happens on D3D11 and D3D9 (new path).
But when I set MPC-HC to Vista compatibility mode, and madVR shows D3D9 (old path), there is no issue. I can rapidly pressing Alt in fullscreen mode. It switch between windowed and fullscreen windowed without any delay and frame drops.

So what is the difference between D3D9 (new path) and D3D9 (old path)?

At the end I think it is an AMD driver issue, because I don't have the issue in an Intel and NVIDIA GPU and it is unrelated to the software. But MPC-HC and madVR gives me the chance to isolate the problem to the specific 'technology'.

I tested MPC-HC also with EVR-CP and MPC Video-Renderer without Vista mode and there are also no frame drops in fullscreen when GUI element gets displayed. So there is no presentation in this renderer...?

Thank you for any information about this kind of technology :)

huhn

28th July 2020, 18:54

old path is using a back buffer instead of presenting frames in advances.

d3d11 adds different feature like rendering in 10 bit.
it using dx11 instead of dx9.

i can not really help you in your issue because you are using thinks like vista compatibility mode and such instead of changing these setting directly in madVR.

Morku

28th July 2020, 19:14

This is already good to know.

i can not really help you in your issue because you are using thinks like vista compatibility mode and such instead of changing these setting directly in madVR.
What? :D
It's just something I have found out and can be easily revert.
If you tell me how to set up in madVR for the same result, I would like to test.

I have unchecked "present several frames in advance" in windowed mode related to you answer, but the result is the same. Frame drops.

Siso

28th July 2020, 19:29

SirMaster

28th July 2020, 20:03

Is it possible to use AiUpscale with madVR?

Like can you use AiUpscale to up-scale the image before it gets to madVR so madVR just sees it as a 4K 4:4:4 source and doesn't need to apply any additional up-scaling?

Assuming this is possible in MPC, is it even worth setting up over NGU?

huhn

29th July 2020, 07:40

I'm on 3440x1440p 120hz now, and I have a problem with the present queue not being filled entirely it stays 5-8/8, this happens when using NGU Sharp High, everything else is "let madvr decide". This issue appears mostly on 1.85:1 and 1.78:1 1080p movies, card is GTX 1050 ti. Driver is 441.41 win 7 64 bit.

as long as you are not dropping frames just ignore it.

@SirMaster
yes with some avisynth knowledge you can use it in madVR.

if the scaler is compatible with the license and is better/faster or a real realtime alternative you can be sure madshi will add it anyway.

if you want the chroma scaler which looks so good on paper is either the same as biliteral in madVR or a new version of it both are made by shiandow and it's even possible to update the madVR bilateral version(which i will do for fun now). i can not recommend this scaler (at least the old one)it's either very good but it likes to fail very hard from time to time too it's just the nature of how it working if the luma can't guide it or is a wrong guide biliteral can get into troubles.

reconstruction is another luma guided chroma scaler but it pretty slow and i can't remember major issues with it.

@Morku
maybe start witha ascreen of the OSD and default settings and name your hardware.

Morku

29th July 2020, 12:57

@huhn

Sure. madVR is in standardsettings. I have changed Upscaling to NGU, reduce banding artifacts.
OSD looks like that when running normally: https://i.imgur.com/bJS91rk.png

When I start pressing Alt over and over, it looks like that: https://i.imgur.com/OAmuteQ.png
The average state rise high, even when the videofile is paused.

I also noticed, that when it changes from "fullscreen windowed" and "windowed" also changes between 10 bit and 8 bit. Maybe this is also causing the lag? There is no bit information in D3D9 (new path).
Any way to keep it 10 bit in windowed? Or 8 bit in fullscreen windowed to test?
On my main main computer, it stays always on 8 bit in fullscreen windowed.

The AMD display setting is set to YCbCr 4:4:4 and 12 bpc. When I try to change it, it revert the setting atuomatically back. It is connected to a Sony KDL-32EX725 (about 8 years old) with HDMI.

My system is Intel NUC NUC8i7HVK with a Intel® Core™ i7-8809G Prozessor and integrated Radeon™ RX Vega M GH graphics and 16 GB Memory.
Windows 10 2004 19041.388 and BIOS, Firmware and drivers are on latest version.
Thank you for help.

Siso

29th July 2020, 15:36

as long as you are not dropping frames just ignore it.

Thanks for the info, huhn.

clsid

29th July 2020, 15:58

I also noticed, that when it changes from "fullscreen windowed" and "windowed" also changes between 10 bit and 8 bit. Maybe this is also causing the lag? There is no bit information in D3D9 (new path).
Any way to keep it 10 bit in windowed? Or 8 bit in fullscreen windowed to test?In the devices section of madVR settings you can specify the native bitdepth of the screen. Try setting that to 8-bit.

Ejziponken

29th July 2020, 16:09

@madshi any chance we get an update that fixes the new Nivida API and HDR?

Morku

29th July 2020, 16:34

@clsid

Ah, found it. It stays in 8 bit when fullscreen windowed or just windowed. Okay, but unfortunately this is not the root of my issue, the frame drops are still. So the change between 8 bit and 10 bit is not the issue :\

huhn

29th July 2020, 17:31

try to disable the IGPU in the bios for a test if that system allows that.

your system may just switch between the GPU when the 3D application stops using full screen.

another thing you can try is forcing a GPU to run with MPC-HC.

what so ever you get rendertimes that are clearly not normal and that may explain it.

SamuriHL

29th July 2020, 18:37

@madshi any chance we get an update that fixes the new Nivida API and HDR?

That is extremely unlikely any time soon. He is focused on launching the Envy. He had popped into the AVS thread a few weeks ago and said a new build was maybe going to drop "in a few weeks" but then came back and said he was being overly optimistic. And that new beta build is very unlikely to fix this problem even when it does eventually drop. So, we either live with the problem or stick with older drivers for now.

Morku

29th July 2020, 20:59

@huhn
The BIOS allows me to disable the Intel GPU. But the result... is the same.

I also tried to set MPC-HC to use only Intel GPU, but the result is even worse with AMD. Still, I think AMD is always responsible for video out. You can't disable it. So at least one more confirmation that I think it is a AMD hardware/driver bug in relation to Windows OS.

Sure, with high rendertimes, the result are frame drops. But I still don't know what's the cause (and why there is no issue in Vista mode...).

When I set the task-manager on front, there is also no issue. So to fix the issue, "something" have to be displayed to keep Windows GUI busy (a 1x1 invisible pixel would be nice...?).
And since the issue is also with other videoplayers, like the Netflix App (navigation bar fade in and out) or with Microsoft Movies & TV, it is unrelated to a software or madVR. But all have "something" in common.

I created a new short video to summarize and show a little more detailed (with OSD): https://www.dropbox.com/s/axk0p9ois724l60/choppy5.mp4?dl=0

Dogway

30th July 2020, 21:39

What is the meaning of HDR peak white for an SDR HDTV calibrated to 48nits? Does that mean diffuse white is 48nits, or is that the peak white?

Alexkral

31st July 2020, 02:46

What is the meaning of HDR peak white for an SDR HDTV calibrated to 48nits? Does that mean diffuse white is 48nits, or is that the peak white?

For SDR diffuse white and peak white mean the same.

Dogway

31st July 2020, 18:20

For SDR diffuse white and peak white mean the same.

Is that how the BT2390 tonemapper works? compressing peak white to diffuse white?

EDIT: So where it says Target Peak Nits I should input 48nits? It doesn't allow any lower than 100nits which is only valid for surrounds of 5 nits -not dark surrounds-.

Obveron

31st July 2020, 19:44

Alexkral

31st July 2020, 20:17

Is that how the BT2390 tonemapper works? compressing peak white to diffuse white?

EDIT: So where it says Target Peak Nits I should input 48nits? It doesn't allow any lower than 100nits which is only valid for surrounds of 5 nits -not dark surrounds-.

SDR should be calibrated to 100-120 nits, this way with BT.2390 a 10000 nits HDR peak white is mapped to 100 nits, and 100 nits are mapped to around 48 nits. If the HDR peak white is less than 10000 nits the compression is also less, for example, if it equals 1000 then 100 nits are mapped to around 69 nits.

JarrettH

31st July 2020, 20:37

Interesting measurements!

Where did the idea of using NGU AA for chroma originate? It was so long ago. I remember it reportedly still being very sharp.

huhn

31st July 2020, 20:49

it comes from testing images.

NGU AA super seeded nnedi3 by been mostly faster and better with similar strong points and weak points.

Dogway

31st July 2020, 20:56

SDR should be calibrated to 100-120 nits, this way with BT.2390 a 10000 nits HDR peak white is mapped to 100 nits, and 100 nits are mapped to around 48 nits. If the HDR peak white is less than 10000 nits the compression is also less, for example, if it equals 1000 then 100 nits are mapped to around 69 nits.

That means I need two calibrations one for SDR content (48 nits) and another for HDR (100 nits), and play with TV brightness settings... Not convenient. Also films mastered at 10000 nits are rare, specially < 2010 titles.

If you are in a black box (dark surround) diffuse white should map to 48 nits, 100 nits is for mastering or dim surrounds (link1 (https://liftgammagain.com/forum/index.php?threads/rec-709-100-nits-brightness-neccessary.11491/#post-114565), link2 (https://partnerhelp.netflixstudios.com/hc/en-us/articles/360000591787-Color-Grading-Calibration-Guidelines)).

I will ask madshi if he can allow lower target peaks, or better yet allow diffuse white mapping instead of target peak. This way we can lower SDR content from 100 nits to 48 within madVR, and do the same (via a profile group) with HDR content.

Siso

1st August 2020, 14:50

Is upgrading from GTX 1050 Ti to GTX 1660 Ti a good option for madvr?

Obveron

1st August 2020, 22:58

Hi there, I'm wondering if someone might be able to point me in the right direction here. I'm trying to get 3d framepacking working.
I have Nvidia 3d 1080p/24 framepacking mode automatically being enabled when I start a 3d file. However the content is being displayed in Side-by Side mode rather than frame alternating.

my display output is set to auto, the renderer settings are set to output 3d. I'm definitely using the LAV MVC filter.
It seems to be actually mostly working, my TV is going into 1080p framepacking mode properly, the MVC stream must be decoded properly but it's showing in side-by-side mode for some reason. I can select other display outputs like over under etc and they work too, but I can't get it to output as framepacked even though my TV is going into framepacked mode just fine.

one thing to note, I had to uncheck 'use DX11 for presentation' or it would outright crash the player when opening the file.

Windows 10 1803
MPC-HC 1.9.6.7
LAV Filters 0.74.1
madVR 0.92.17
Nvidia 441.08 with 3D vision injected
RTS 2060 Super
9700k

Thanks.

So madvr 3d still works well with Nvidia's last official 3d vision driver, 425.31. If you use a newer driver with 3d vision injected it breaks madvr framepacking support. It will kick the output into framepacking just fine, but it renders as side-by-side despite the output being in framepacked. I suspect there's something wrong in how madvr detects the output is in 3d framepacked, it may be as simple as that new nvidia driver versions are wrongly ignored by madvr (maybe an assumption that the new drivers don't support 3d, which they do fine if you inject 3d vision into the driver)

FYI, new nvidia drivers with 3d vision works excellent in 3d games, and 3d framepacked MVC players like Stereoscopic player and PowerDVD also work fine. (but can't compare to madvr quality!)

ryrynz

3rd August 2020, 07:58

Is upgrading from GTX 1050 Ti to GTX 1660 Ti a good option for madvr?

Yes, should be almost twice as capable and you'd be able to unlock much better settings.

Siso

3rd August 2020, 10:26

Yes, should be almost twice as capable and you'd be able to unlock much better settings.

Sounds good, thank you.

tp4tissue

3rd August 2020, 11:27

Is upgrading from GTX 1050 Ti to GTX 1660 Ti a good option for madvr?

It should work fine, but if it was me, I'd rather get a used 1080, as they're still more compatible, who knows when Madshi will fix all the bugs for Turing series cards.

Asmodian

3rd August 2020, 12:15

bugs for Turing series cards.

I have a Turning, what issues are you referring to?

Siso

3rd August 2020, 12:18

I have a Turning, what issues are you referring to?

Indeed, what issues?

SamuriHL

3rd August 2020, 17:30

They aren't bugs, they're nVidia changes that madvr needs to be updated to handle around HDR.

Siso

3rd August 2020, 19:29

They aren't bugs, they're nVidia changes that madvr needs to be updated to handle around HDR.

It applies to HDR only, right? Not SDR?

huhn

3rd August 2020, 21:00

the turing "bug" is limited to user that need to lower the present queue to avoid judder.

no one has reported that they couldn't fix this issue in the last i don't know 18 month or so...

jkauff

4th August 2020, 02:25

I have a GTX 1660 Super in my desktop (4K monitor) and a GTX 1080 in my HTPC. I use the same madVR settings on both, and they perform pretty much identically.

Filmgeek47

4th August 2020, 19:30

So madvr 3d still works well with Nvidia's last official 3d vision driver, 425.31. If you use a newer driver with 3d vision injected it breaks madvr framepacking support. It will kick the output into framepacking just fine, but it renders as side-by-side despite the output being in framepacked. I suspect there's something wrong in how madvr detects the output is in 3d framepacked, it may be as simple as that new nvidia driver versions are wrongly ignored by madvr (maybe an assumption that the new drivers don't support 3d, which they do fine if you inject 3d vision into the driver)

FYI, new nvidia drivers with 3d vision works excellent in 3d games, and 3d framepacked MVC players like Stereoscopic player and PowerDVD also work fine. (but can't compare to madvr quality!)

Just an addendum to this... Madshi has mentioned over at Avsforum that he's got a private beta running that has apparently fixed this issue. No idea when it will be freely available, but it's good to know that there's a solution in the pipeline.

wolfman2791

6th August 2020, 03:03

Greenhorn

6th August 2020, 05:24

Guys... just take the time to learn MPV and the options, shaders, etc. I've got it looking just as good, and even slightly better, than madvr. It was about a month of learning curve (I didn't have a lot of time to spend on it). Well worth it though. Now I don't have to worry about updates that may or may not happen.

I'd say MPV has far less than a month's learning period (maybe a long afternoon's) if you're used to editing config files by hands and reading FOSS documentation for work or pleasure, but possibly more than a month otherwise.

MPV vs MPC/PotPlayer/Zoom(?) is probably a better comparison than MPV vs madVR, and I really don't see an overlap between their target audiences at all. It's a flexible and powerful piece of software, but just absolutely not for someone who only wants to watch their collection in good quality with minimal startup time.

Stax's mpv.net is a good intermediate, but still (self-acknowledged as being) for advanced users.