Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th July 2015, 23:42   #32141  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,323
Quote:
Originally Posted by Warner306 View Post
The discussion in this thread may be useful regarding the benefits of DXVA2 Copy-back vs Nvidia Cuvid: http://yabb.jriver.com/interact/index.php?topic=80258.0.
Wooow, thank you for the link!
I had been using CUVID so far, now I switched to DXVA2 copyback, and I haven't known this:
"1. ... DXVA2 Copy-Back allows the graphics card to drop down to the medium power state if the GPU load is low enough."

Although I have been maxed out the powerstate to P5, gpu was always used at P5 with CUVID, even when MPC-HC was paused or stopped, now it goes down to the lowest states in these cases as well: less power -> less heat -> less noise.
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED77G2(2160p@23/24/25/29/30/50/59/60Hz) | madvr config

Last edited by chros; 25th July 2015 at 23:46.
chros is offline   Reply With Quote
Old 26th July 2015, 00:36   #32142  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by huhn View Post
should be possible with this or NV/KHL d3d10 but who said they will not remove this next version?
Totally agreed, I really hope due to this madshi might give a non-OpenCL implementation of NNEDI3 a higher priority.
Not being able to use NNEDI3 would be a tragic loss, at least to me.
aufkrawall is offline   Reply With Quote
Old 26th July 2015, 09:18   #32143  |  Link
ShadyCrab
Registered User
 
Join Date: Jul 2015
Posts: 16
Using 0.88.20, when a MPC-HC OSD element pops up (volume, skip, etc) there is a very minor stutter, as though 1-2 frames had to repeat. Its noticeable, but isn't consistent in its severity or length. Big improvement from earlier versions, but not pre-OSD rewrite smoothness.

The madVR OSD seems to cause this issue too. Its like theres something off, almost like smooth motion was disabled, but less extreme.

GTX 660, MPC-HC (latest nightly) internal LAV, ISR, etc. D3D11 exclusive.
ShadyCrab is offline   Reply With Quote
Old 26th July 2015, 09:49   #32144  |  Link
Sunset1982
Registered User
 
Join Date: Sep 2014
Posts: 280
Quote:
and about openCL looks like nvidia has removed cl_nv_d3d9_sharing in newer drivers.
What means newer drivers? What was the last Version with cl_nv_d3d9_sharing in it?

Is there a windows 10 working driver with that extension?
Sunset1982 is offline   Reply With Quote
Old 26th July 2015, 11:12   #32145  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
not sure maybe 353.30 still has it maybe not.
huhn is offline   Reply With Quote
Old 26th July 2015, 15:43   #32146  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
I rather recommend 353.49, since it includes fixes for TDR issues. NNEDI3 OpenCL works with these drivers.
aufkrawall is offline   Reply With Quote
Old 26th July 2015, 23:12   #32147  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Akeno View Post
I've made a short comparison along the lines of madshi's post comparing Super-XBR and NNEDI3 in regards to SuperRes.
Source chosen specifically for the details in the eyes. These get extremely soft when upscaling.

GroundTruth -|- 50% downscaled

Without Refinement
NNEDI3 -|- Super-XBR

I'm using s-xbr 100 for these comparisons. NNEDI looks a better than s-xbr. You can see that the lines are a bit thicker especially in her eyes and there's small ringing around her chin and on the flash cards she's holding. S-xbr is a bit sharper than NNEDI in this example but NNEDI is closer to the groundtruth here.

SuperRes: Strength 2 / Radius 0.66
NNEDI3 -|- Super-XBR

With SuperRes, the images look nearly identical. NNEDI benefits a tiny bit from SuperRes. The image is slightly sharpened at the cost of tiny aliasing all around. You can see it on the lines of the flashcards. Super-XBR benefits a lot more from SuperRes as the thickness around the lines is significantly reduced but the ringing is still present.

Conclusions
So here's SuperRes on cartoon and anime content. No horrible directional artifacts to be found unlike the trees in the castle examples. All in all, NNEDI3 and Super-XBR produce nearly identical results when combined with SuperRes. NNEDI3 is still superior though as Super-XBR does produce more artifacts (look at the lower edge where the glass meets the door frame next to her shoulder and on the edges of her uniform) and ringing. If the image could be sharpened just a teeny bit more, we'd be extremely close to the groundtruth. Maybe a change in finesharp's algorithm to decrease artifacts or a denoise filter with finesharp could do the trick.

I'm also going to take back what I said about adaptive sharpen as an image enhancer. It completely ruins the soft glow she has on her face and makes the image look processed.
Thanks. Your groundtruth is not the same frame, though. But I think in this case it's probably not a big problem.

Quote:
Originally Posted by pureocean View Post
I have black screen problem. My GPU is Radeon HD 3200. I use Potplayer (last version). Catalyst display driver is last version. A sample video. When in this video jump to 07, 08, 09, 10 and 18, 19, 20 seconds, it's displaying black screen for an instant. Which settings can fix this problem? I don't know using how "madVR debug.ax".
For an instant? And after that it works fine? Doesn't sound like a very big problem. Just a cosmetical issue?

Quote:
Originally Posted by Braum View Post
I did a short comparison of upscaling refinement options, mainly for myself, needed to know what was best for anime content.

Source : 1280x720
Monitor : 1680x1050

Chroma upscaling : Super-xbr 75
Image downscaling : Lanczos 4 AR LL
Image doubling : Super-xbr 75 (double luma/chroma)
Image upscaling : Jinc AR

Zoom 400%

Original

SuperRes Strengh 2 Radius 0.65 (the higher the strengh, the worst the result)

Adaptive Sharpen 0.3

Adaptive Sharpen 0.1

Finesharp 1.0

So SuperRes mostly damage the original content, adaptive sharpen 0.3 is way too much, so I'll go for Finesharp 1.0/1.5 or Adaptive Sharpen 0.1/0.2.

Finesharp seems to be better for movie content (bluray, high quality source) and adaptive sharpen for anime content (relatively new animes), at least that's my preferences.

edit : I decided to go with adaptive sharpen 0.2
I personally cannot judge anything at 400% nearest neighbor zoom. There's also no groundtruth to compare to. So basically I can't comment on your images or comments at all.

Quote:
Originally Posted by 6ari8 View Post
I believe the stuttering issue started with v0.88.16b.
Ok, please try again with v0.88.21.

Quote:
Originally Posted by ryrynz View Post
With regards to what Nev said over on the LAV thread

Can you give us any firm info on this?
Copyback produces the same quality as software decoding. Native DXVA decoding (and also DXVA deinterlacing and scaling) is problematic because Direct3D doesn't allow me to directly access the decoded NV12 surfaces, so I have to use tricks to make it work. Depending on the GPU and the driver it might work out well or badly. Usually if it works out badly, it's either a total misconfiguration in your GPU control panel settings. Or if your GPU control panel settings are ok, the worst that should happen is that the chroma channel is a tiny bit less detailed. Should have no effect on luma.

Quote:
Originally Posted by aufkrawall View Post
As I said, the foreground looks totally clear to me in its native resolution.
Why is this not a valid point, according to you?
Judging what is "totally clear" and what is not is subjective. Judging how a "totally clear" small image should look like 400% zoomed up is even more so. The only way to make things objective is if we have something to compare to.

Quote:
Originally Posted by aufkrawall View Post
Is your display still sub-1080p? I really doubt it makes sense to judge about sharpness if you can count every single pixel.
1080p front projection.

Quote:
Originally Posted by daert View Post
I have a problem with MPC-BE and madvr. If I set "treat 25p as 24p" in madvr, display mode won't change to 24p when I open a 25p video: it's stuck at 60p. If I use MPC-HC the issue doesn't appear. I'm using MPC-BE 1.4.5.579 and madvr 0.88.20
Check the source fps information in the madVR debug OSD. Maybe it's incorrect in MPC-BE?

Quote:
Originally Posted by leeperry View Post
Righty, took me a while to find the ideal picture but I think this one works very nicely:

original untouched 1080p BD screenshot(not captured by me):

sxbr75+SR3@0.41LQ(my favorite)
sxbr75+SR3@0.41HQ
NEDI+SR3@0.41LQ
sxbr75+AS0.5
NNEDI3 for luma+chroma@16 neurons +SR3@0.41LQ
NNEDI3 for luma@32 neurons+J3AR chroma+SR3@0.41LQ
NNEDI3 for luma+chroma@32 neurons

sxbr75+SR1@0.66LQ
sxbr75+SR1@0.66HQ
sxbr75+SR2@0.66HQ
sxbr75+SR3@0.66HQ
It's an interesting test picture because even NNEDI3-256 still has noticeable aliasing in some image areas. Of course SuperRes doesn't improve on that.

I find it hard to understand your image descriptions, though. I'm not sure if @0.xx is the radius of the strength?? Or is it sometimes this and sometimes that?

Quote:
Originally Posted by ryrynz View Post
Madshi, looks like there's an issue here. On my 750 Ti there are considerable differences between running LAV in copy-back mode and native DXVA2.

http://screenshotcomparison.com/comparison/136044
This almost looks like DXVA does some sort of overscan scaling or stuff. Is everything in the GPU control panel set to neutral/disabled/application controlled?

Quote:
Originally Posted by Warner306 View Post
Now that Kodi DSPlayer has integrated low latency mode, I have noticed a new issue. I believe this addition has made 1080p60 playback a little stuttery with some noticeable blurring on moving objects. It is subtle, but I cannot detect the same problem at 1080p24.

I have switched between MPC-BE and DSPlayer at 60hz and find DSPlayer is now less smooth - the blurring on objects being particularly noticeable.

Was 3/2 pulldown properly tested when low latency mode was added? Something does not look right at 1080p60 when played through DSPlayer.
I think there's a bug in v0.88.20 which keeps low latency mode active sometimes although it shouldn't be active. I suppose that motion smoothness might not perfect for all users in low latency mode - although it works just fine on my PC with all my GPUs. In any case, during normal video playback low latency mode should be disabled, and then v0.88.21 should hopefully be back to v0.88.16 reliability.

Quote:
Originally Posted by Gravitator View Post
All kind people hello!
Version 0.88.16 during pause 0% GPU (MPC-HC 1.7.9.54);
Version 0.88.20 when paused consumes 40% of the GPU. - Перемудрил Мад;
(Win x64, Pentium E6600, nVidia GTX750 (DR 350.12).
Quote:
Originally Posted by nevcairiel View Post
Thats expected, madVR now keeps drawing the frame while paused.
Quote:
Originally Posted by sneaker_ger View Post
But 40%? Shouldn't only presenting be done while pausing (+maybe OSD changes), no scaling/filtering?
Quote:
Originally Posted by nevcairiel View Post
40% is a relative value, so without knowing the power state of the card, its not that meaningful.
It may have clocked down and show a high utilization.

But ultimately madshi will have to comment on what it really does in pause mode.
40% does seem a bit high, but as nevcairiel says, it depends on the GPU clock. If the GPU clock is very low, 40% is not so much. GPU consumption in paused mode highly depends on the refresh rate, because madVR will present one frame for each VSync, and redraw the OSD for each. I seem to get near 0% GPU consumption on my PC in paused state, though.

In any case, currently madVR *always* draws in paused/stopped mode. I will change that in a future version so that it only draws when it's needed. That will depend on the media player, though (which OSD APIs they're using).

Quote:
Originally Posted by Thunderbolt8 View Post
my point is when watching a movie which needs to be upscaled it will not be downscaled first then. only upscaled. so the upscaled picture should be compared to the source image to clarify which algorythm comes closest to the source at this resolution. because thats simply the resolution this movie will be watched and not at the same resolution as the source image.

my point is that I am questioning this method of sclaling into the other direction first and then getting back to the original size of the image, because we dont know in how far the result of the first scaling process might influence the result of the 2nd one, the one we want to look at. you wouldnt have this problem when directly applying the scaling process you want and compare from there.
I understand your concern. But please understand that most of today's content is actually a downscale, produced by the studios from their masters. DVDs were usually downscaled from 2K masters. Better Blu-Rays are downscaled from 4K masters. So upscaling video that was formerly downscaled is not something unusual, it's what we do every day.

The purpose of first downscaling and then upscaling again is that this is the only way we can objectively judge whether the upscaled image comes near to the original. If we don't use this approach, we have e.g. a DVD resolution source and an 1080p upscale, but whether the upscale is good or not nobody can say. Different upscalers, different sharpening algorithms produce different "looks". Some users prefer this, other users prefer that. Without having the original to compare to, if you ask 100 different users for which algorithm combination they prefer, you'll get 98 different answers.

Quote:
Originally Posted by KoD View Post
the issue in my original post, about the frame dropping and queue depletion happening only when 10bit output is sent to the TV is still there in 0.88.20, just like in 0.88.19 and 0.88.12. With 0.87.21 this issue is not present, but there was no way to output 10 bit color back then.
There is a known issue if D3D11 does not officially support the refresh rate you want to use. In that case some GPU drivers run into trouble with queues not filling properly, especially when using a large number of prepresented frames. There's no solution to this. madVR is able to make D3D11 use the refresh rate you want, but with some GPU drivers these queues-not-filling problem is the consequence. Probably if you limit yourself to 1080p60, you'll not have this problem.

Quote:
Originally Posted by mogli View Post
When displaying a movie one frame at a time in MPC-HC one sees a future frame flashing shortly before the correct one is shown. This is new since a few madVR versions ago.

Is this a known issue?
Not really. But different users had a couple of different weird issues. Try v0.88.21.

Quote:
Originally Posted by DragonQ View Post
I upgraded to the latest MadVR on both my laptop and desktop and now have the same issue with both: deinterlacing no longer activates for 1080i/25 AVC videos in MKVs. I get a "DXVA processing failed" message. 576i/25 MPEG2 videos in MKVs seem to work fine.

The laptop has Intel and nVidia GPUs, the desktop has AMD. 0.88.19 also suffers this problem but 0.88.15 doesn't, so something happened somewhere between those two versions to break this.
Try v0.88.21. If that still fails, please upload a debug log.

Quote:
Originally Posted by ShadyCrab View Post
Using 0.88.20, when a MPC-HC OSD element pops up (volume, skip, etc) there is a very minor stutter, as though 1-2 frames had to repeat. Its noticeable, but isn't consistent in its severity or length. Big improvement from earlier versions, but not pre-OSD rewrite smoothness.

The madVR OSD seems to cause this issue too. Its like theres something off, almost like smooth motion was disabled, but less extreme.

GTX 660, MPC-HC (latest nightly) internal LAV, ISR, etc. D3D11 exclusive.
Try v0.88.21. You may still have this issue when activating the FSE seekbar, but hopefully for all other OSD elements this issue might be gone in v0.88.21.
madshi is offline   Reply With Quote
Old 26th July 2015, 23:14   #32148  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
madVR v0.88.21 released

http://madshi.net/madVR.zip

Code:
* OSD rendering back to 0.88.16 logic, except when low latency mode is active
* fixed: DXVA processing failed when video stream switched resolution
* fixed: render times weren't shown correctly
* fixed: SuperRes bigger radius values could cause artifacts
* fixed: low latency mode sometimes wasn't turned off when it should
madshi is offline   Reply With Quote
Old 26th July 2015, 23:51   #32149  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 934
Quote:
Originally Posted by madshi View Post
Try v0.88.21. If that still fails, please upload a debug log.
The problem persists, unfortunately. I'll try to get a debug log tomorrow evening for you.
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7
DragonQ is offline   Reply With Quote
Old 27th July 2015, 00:58   #32150  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
Quote:
Originally Posted by huhn View Post
not sure maybe 353.30 still has it maybe not.
I have been unable to get NNEDI3 in madVR working with the Windows 10 Nvidia drivers 353.54. Other OpenCL tests do work and by uninstalling 54 and reinstalling 353.30 NNEDI3 works again. Windows Update will automatically re-install 353.54 which breaks it again.

Tested with a 980 Ti, madVR v0.88.20, and Windows 10 Pro (not preview).
__________________
madVR options explained

Last edited by Asmodian; 27th July 2015 at 01:01.
Asmodian is offline   Reply With Quote
Old 27th July 2015, 01:07   #32151  |  Link
Sunset1982
Registered User
 
Join Date: Sep 2014
Posts: 280
Quote:
Originally Posted by Asmodian View Post
Windows Update will automatically re-install 353.54 which breaks it again.
If you dont know already: you can disable automatic driver updating in windows 10
Sunset1982 is offline   Reply With Quote
Old 27th July 2015, 01:21   #32152  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
AFAIK madVR uses cl_nv_d3d9_sharing for nvidia. so it can't work with these drivers.

nvidia removed this extension nothing you can do about you can only hope the next WHQL driver have them again so nvidia user can use nnedi3 with windows 10 if not you have to hope madshi is spending time on it. which could be a huge waste of time.

CL_KHL_d3d10_sharing could have the same copyback issue like AMD cl_khl_dx9_media_sharing. and who know if nvidia isn't removing cl_nv_d3d11_sharing too? i mean it looks like they have nothing better to do right now them crippling there own drivers.

there are workarounds to stop the windows updates for nvidia driver but wrong thread.
huhn is offline   Reply With Quote
Old 27th July 2015, 01:38   #32153  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by madshi View Post
It's an interesting test picture because even NNEDI3-256 still has noticeable aliasing in some image areas. Of course SuperRes doesn't improve on that.

I find it hard to understand your image descriptions, though. I'm not sure if @0.xx is the radius of the strength?? Or is it sometimes this and sometimes that?
It does come from a benchmarking BD: HD Benchmark 2nd Edition
Quote:
Every pattern was created using our exclusive ultra-high-precision software tools and represents the state of the art in video reproduction.
They have many other nasty bits such as

"sxbr75+SR3@0.41" in .15: 3 passes, 0.41 strength.
"1@0.66" in .20: first figure is strength, second is radius.

Anyway, I was hoping for you explaining me how HQ looks so much closer to the ground truth than LQ and that didn't happen, I take it that my screenshots were hard to kill then.

I won't give up on SR(mostly due to the magic it does on motion blur, even more striking on 29.97fps footage O-M-G talk about a one-way ticket!), you were kind enough to add a kludge in order to force LQ in .20 but I take it that the seperate knobs for the number of passes and strength will never come back...even as kludges if I ask very very nicely? And this ** radius stuff will replace them?

Even 4*0.41 or 3*0.42 don't look nearly as good as 3*0.41 IME so I'm not willing to compromise whatsoever, your "pretty much the same" and "roughly the same" don't cut it by a very long shot so it sounds like I'll stick to .15 and just got myself a lot of free time suddenly.

If 2 passes at 1.0 are supposed to look "roughly the same" as 3 passes at 0.41 then I wonder why you spent countless hours nitpicking about a lot of details in mVR, such as chroma for instance when many ppl claim that differences IRL are completely invisible......nothing in what you do goes by the "pretty much the same" principle so color me surprised to read that you are willing to kill the SR golden goose *killer* feature in such a tremendous and dramatic way(to me anyway)

And if you are so concerned about the GPU consumption wasted by one extra pass then I wonder why you even allow 256 neurons NNEDI3 to begin with, this is not consistent at all. I couldn't care less about a few extra percents of GPU load if PQ looks better to me, I truly wonder how you came up with the idea that mixing the strength and number passes together as a single knob could ever work

But truth be told, I can't really think of anything to improve in .15 tbh(proper SR on chroma woulda been nice but hardly vital), PQ is truly beyond words so I'm totally cool with calling it my very own 1.0 and live happily ever after......and no more e-drama for you to cope with(well except when that other .15 LQ lover will be back from vacation next week ^^), happy happy joy joy

My only problem atm is that 1080p movies got more resolution but 720p encodes get the magical SR motion-blur treatment, choices..

I also don't understand why madHcNet32.dll is locked even when mVR is closed lately, I don't have any A/V resident app running and virustotal doesn't consider my mVR installation infected...oh well, that never happened before, it's only after a zillion .15/.20 rollings that it started acting up.

Last edited by leeperry; 27th July 2015 at 02:11.
leeperry is offline   Reply With Quote
Old 27th July 2015, 04:47   #32154  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Madshi,

I suppose low latency mode is something that a player would call for not the user, because I don't see an option for that?
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.
James Freeman is offline   Reply With Quote
Old 27th July 2015, 05:39   #32155  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by James Freeman View Post
I suppose low latency mode is something that a player would call for not the user, because I don't see an option for that?
You got it.
ryrynz is offline   Reply With Quote
Old 27th July 2015, 08:08   #32156  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 934
Quote:
Originally Posted by madshi View Post
Try v0.88.21. If that still fails, please upload a debug log.
Debug log here.
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7
DragonQ is offline   Reply With Quote
Old 27th July 2015, 12:21   #32157  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
Quote:
Originally Posted by madshi View Post
l understand your concern. But please understand that most of today's content is actually a downscale, produced by the studios from their masters. DVDs were usually downscaled from 2K masters. Better Blu-Rays are downscaled from 4K masters. So upscaling video that was formerly downscaled is not something unusual, it's what we do every day.

The purpose of first downscaling and then upscaling again is that this is the only way we can objectively judge whether the upscaled image comes near to the original. If we don't use this approach, we have e.g. a DVD resolution source and an 1080p upscale, but whether the upscale is good or not nobody can say. Different upscalers, different sharpening algorithms produce different "looks". Some users prefer this, other users prefer that. Without having the original to compare to, if you ask 100 different users for which algorithm combination they prefer, you'll get 98 different answers.
Would it at least make sense to limit ourselves to the source and scaling resolutions that make most sense for this? E.g. 720p to 1080p or 1080p to 4k or 4k to 1080p? Not sure if scaling something like 400 pixels to 800 pixels would be of help for a media player (especislly not in the future when 4k becomes the standard)
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack)
Thunderbolt8 is offline   Reply With Quote
Old 27th July 2015, 15:16   #32158  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
madshi, even with 0.88.21 that has the OSD rendering back to 0.88.16, the image is now black while seeking forward / backward.
This does not happen with the true/pure 0.88.16, any way around it?
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 27th July 2015, 16:06   #32159  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by DragonQ View Post
The problem persists, unfortunately.
Does this test build fix it?

http://madshi.net/madVR8821b.rar

Quote:
Originally Posted by leeperry View Post
"sxbr75+SR3@0.41" in .15: 3 passes, 0.41 strength.
"1@0.66" in .20: first figure is strength, second is radius.
Might have made sense to mention that in your original post... It's quite confusing if you use the same syntax to describe different settings, without actually explaining that anywhere.

Quote:
Originally Posted by leeperry View Post
Anyway, I was hoping for you explaining me how HQ looks so much closer to the ground truth than LQ and that didn't happen, I take it that my screenshots were hard to kill then.
I didn't comment on the images because I wasn't sure which settings you were using, see above.

From what I can see, your comparison is interesting, but not very goal oriented. You've posted a bunch of different screenshots with different settings, and all the conclusions I can draw from them are these:

1) Using a bunch of somewhat different settings results in images which look somewhat different.
2) You prefer one specific set of settings with one specific madVR version over a different set of settings with a different madVR version.
3) Latest SuperRes with default settings does produce aliasing with your test image, while with your preferred settings it's less of a problem.
4) With your specific test image, some other algo changes I did between v0.88.15 and v0.88.21 have a certain effect, too.

I'm not totally sure what your goal with those images were. If you just wanted to show that your settings with v0.88.15 produce a somewhat different result to default settings with v0.88.20 when using the "BilinearSuperRes" hack, you've succeeded, but other than that it's hard to draw any hard conclusions.

A goal oriented test would have been to use v0.88.15 for all images, and then to compare 3 passes with 0.65 strength to 2 passes with 1.00 strength, to check if there's a noticeably difference in image quality. But you didn't do that, so you didn't put any weight to your wish that you want to be able to adjust passes and strength separately.

FWIW, SuperRes is still not "finished". There's one change I plan to do for the next build, which will change the look of the image slightly again (but not too much). Furthermore I will probably increase the radius by default which should get rid of most aliasing problems.

Quote:
Originally Posted by leeperry View Post
If 2 passes at 1.0 are supposed to look "roughly the same" as 3 passes at 0.41 then I wonder why you spent countless hours nitpicking about a lot of details in mVR, such as chroma for instance when many ppl claim that differences IRL are completely invisible......nothing in what you do goes by the "pretty much the same" principle so color me surprised to read that you are willing to kill the SR golden goose *killer* feature in such a tremendous and dramatic way(to me anyway)
Details in chroma upscaling can be next to invisible in many situations. But there are situations where there's a dramatic difference, and obviously, when judging which algorithms to use, you choose test patterns/images where differences are especially noticeable.

So far nobody has shown any proof that 3 passes with lower strength looks better at all than 2 passes with higher strength. All the evidence so far suggests that both produce nearly identical results. Yes, there are tiny differences, but it's hard to say which is actually better. If there were proof that 3 passes with lower strength would objectively be better, I would consider allowing that, even if it costs more GPU power. But there's no evidence that points in that direction. And I'm not going to waste GPU power on something where nobody is able to produce any evidence of improvement with any test images.

Quote:
Originally Posted by leeperry View Post
I also don't understand why madHcNet32.dll is locked even when mVR is closed lately, I don't have any A/V resident app running and virustotal doesn't consider my mVR installation infected...oh well, that never happened before, it's only after a zillion .15/.20 rollings that it started acting up.
I've not changed anything there. But if your media player still runs, the DLL will still be loaded. Make sure your media player is really closed. It might still be lingering somewhere in your task manager.

Quote:
Originally Posted by Thunderbolt8 View Post
Would it at least make sense to limit ourselves to the source and scaling resolutions that make most sense for this? E.g. 720p to 1080p or 1080p to 4k or 4k to 1080p? Not sure if scaling something like 400 pixels to 800 pixels would be of help for a media player (especislly not in the future when 4k becomes the standard)
The exact source and target resolution doesn't matter too much to any of the scaling algorithms. The scaling factor decides everything. 1080p -> 4k is exactly 2.00x scaling factor. Which is the same as 400 -> 800 pixels.

Quote:
Originally Posted by TheShadowRunner View Post
madshi, even with 0.88.21 that has the OSD rendering back to 0.88.16, the image is now black while seeking forward / backward.
This does not happen with the true/pure 0.88.16, any way around it?
madVR now renders in paused and stopped mode, too. When seeking, the media player usually stops playback for a short time. So madVR might think "oh, I'm in stopped mode, so I'm going to render black now". There's a workaround in place which IIRC blocks rendering from occurring for 1 second after seeks. If your seek takes longer, madVR might be tempted to render black.

This is only a cosmetical issue, right? Why do seeks seemingly take so long in your case?
madshi is offline   Reply With Quote
Old 27th July 2015, 16:10   #32160  |  Link
XMonarchY
Guest
 
Posts: n/a
Is the "Low Latency Mode" some new option or is it enabled by default?

With 88.20, I can set Chroma Upscaling NNEDI3 64n with SR Passes = 4 & Strength = 1 and Upscaling Refinement SR to Strength = 4, Radius = 0.66 and have no presentation glitches.

With 88.21, I get presentation glitches unless I lower Chroma Upscaling SR to Passes = 2 & Strength = 1 and also lower Upscaling Refinement SR to Strength = 2, Radius = 0.66 .

Not sure why - maybe presentation glitches were not properly reported in 88.20?
  Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:12.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.