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 19th July 2015, 12:57   #31941  |  Link
Dlget
Registered User
 
Join Date: Sep 2012
Posts: 55
x64 ?

any chance of x64 release of madVR???
since x64 does better CPU utilization
Dlget is offline   Reply With Quote
Old 19th July 2015, 13:00   #31942  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,477
MadVR already has a 64 bit version. It's in the same package as the 32 bit version.
sneaker_ger is offline   Reply With Quote
Old 19th July 2015, 13:12   #31943  |  Link
Dlget
Registered User
 
Join Date: Sep 2012
Posts: 55
does that mean i can use 64 bit lav filter + mpc be for 10 bit files???
Dlget is offline   Reply With Quote
Old 19th July 2015, 13:21   #31944  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,477
correct
sneaker_ger is offline   Reply With Quote
Old 19th July 2015, 14:00   #31945  |  Link
Nachbar
Registered User
 
Join Date: Jun 2012
Posts: 33
Brightness / limited range question

I noticed my new 4K TV will not display anything above 235 or below 16 when it is set to Full Range. Set to limited I am now able to perceive those values. Should I set it to limited or full range in the driver and in madvr?
Also should I set LAV Video to PC, limited, or untouched? I think untouched is correct for now.
Should I also be using YCbCR instead of RGB?

These are the brightness settings I've found to get reference black to be the darkest black using the black clipping video in the avs hd calibration disc:
When in Full Range in madvr with the driver set to Full: 45 (0-15 are clipped)
When in Limited Range in madvr with the driver set to Full: 27 (no clipping)
When in Full Range in madvr with the driver set to limited: 31 (0-15 are clipped)
When in Limited Range in madvr with the driver set to limited: 16 (no cipping)

I'm going to try out limited/limited for a while and see what I think.

I also noticed no matter what setting I choose I cannot get white to clip above reference white. ALl the white levels show no matter what. Even when adjusting brightness and contrast.

Last edited by Nachbar; 19th July 2015 at 15:40. Reason: added more testing info
Nachbar is offline   Reply With Quote
Old 19th July 2015, 14:22   #31946  |  Link
Dlget
Registered User
 
Join Date: Sep 2012
Posts: 55
Quote:
Originally Posted by sneaker_ger View Post
correct
Nahhh...
It doesn't work.
I just tested with everything x64
Dlget is offline   Reply With Quote
Old 19th July 2015, 14:29   #31947  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 445
Quote:
Originally Posted by Dlget View Post
Nahhh...
It doesn't work.
I just tested with everything x64
It works fine with MPC-HC. Make sure the files are registered by running "install.bat".
Ver Greeneyes is offline   Reply With Quote
Old 19th July 2015, 14:51   #31948  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by Dlget View Post
Nahhh...
It doesn't work.
I just tested with everything x64
Its been working for a couple of months now...
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.
James Freeman is offline   Reply With Quote
Old 19th July 2015, 16:10   #31949  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,463
Quote:
Originally Posted by tFWo View Post
I'll be using this too. HQ is the source of most of the problems I have with Superres. There is a new problem when using this. Strength 1 is too strong with HQ turned off . Maybe add strength 0 that halves the strength.

"Radius" option helps only a little when HQ is on. Turning it higher than 0.75-0.80 does remove most of the artifacts, but it also softens the image considerably. Again I fail to find a purpose for Superres with a trade-off like that.

With HQ off, "radius" is less important. It just has to be just above 0.5 (i set it at 0.7 just to be sure). When it's set below 0.5 aliasing/pixelization appears.
Been running tests for a few days now and I wanted to be 100% sure of my impressions, the thing is that they pretty much match exactly yours

HQ adds a foggy smoke screen onto the picture, 1 is way too strong to be useful to anything(w/o HQ at least) and radius makes very weird artifacts when I mess with it.

TBH this release has completely killed SuperRes for me, I'm kinda tired of whining in this thread to have SR reverted to how it was in .15(which would never happen anyway) so I might either call it a day and stick with it(3 passes at 0.65 is actually quite a bit too sharp, 0.42 looks less edgy) or I might just bite the bullet and give up on SR altogether as it would appear that a combination of sxbr+adaptive sharpen also gives very nice results(too bad the strength of sxbr doesn't come with a knob but AS does...for now at least). Usual story that all roads lead to Rome, hopefully you won't kill AS too by removing its strength knob and adding weird radius options or something

And I wholeheartedly disagree that 2 passes at 1.0 look "pretty much" identical to 3@0.65 in .15 as the former looks way sharper and less detailed....like upscaling posterization and unchecking "refine after every 2X upscaling" makes matters even worse. Oh well.

Last edited by leeperry; 19th July 2015 at 16:13.
leeperry is offline   Reply With Quote
Old 19th July 2015, 16:22   #31950  |  Link
Dlget
Registered User
 
Join Date: Sep 2012
Posts: 55
Quote:
Originally Posted by James Freeman View Post
Its been working for a couple of months now...
Can you tell me extra steps if any required for x64 processing
Dlget is offline   Reply With Quote
Old 19th July 2015, 16:27   #31951  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,477
There aren't really any extra steps.
1. Download and unpack latest madvr
2. Right click "install.bat" -> "run as admin" (read any error messages)
3. run MPC-HC x64 or MPC-BE x64 and set to madvr renderer
4. enjoy
sneaker_ger is offline   Reply With Quote
Old 19th July 2015, 16:28   #31952  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Also run "restore default settings.bat"
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.
James Freeman is offline   Reply With Quote
Old 19th July 2015, 19:19   #31953  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 497
Quote:
Originally Posted by leeperry View Post
Been running tests for a few days now and I wanted to be 100% sure of my impressions, the thing is that they pretty much match exactly yours

HQ adds a foggy smoke screen onto the picture, 1 is way too strong to be useful to anything(w/o HQ at least) and radius makes very weird artifacts when I mess with it.

TBH this release has completely killed SuperRes for me, I'm kinda tired of whining in this thread to have SR reverted to how it was in .15(which would never happen anyway) so I might either call it a day and stick with it(3 passes at 0.65 is actually quite a bit too sharp, 0.42 looks less edgy) or I might just bite the bullet and give up on SR altogether as it would appear that a combination of sxbr+adaptive sharpen also gives very nice results(too bad the strength of sxbr doesn't come with a knob but AS does...for now at least). Usual story that all roads lead to Rome, hopefully you won't kill AS too by removing its strength knob and adding weird radius options or something

And I wholeheartedly disagree that 2 passes at 1.0 look "pretty much" identical to 3@0.65 in .15 as the former looks way sharper and less detailed....like upscaling posterization and unchecking "refine after every 2X upscaling" makes matters even worse. Oh well.
If you disagree and you show samples, madshi will always listen. madshi is known to not ignore your feedback if you have enough data on your hands to proof that what you say should be taken into consideration. I don't get why you invest countless hours in testing, yet, you show no screenshots to prove your point.

How do you expect madshi to react? Believe 20 other people that say A looks more satisfying and agree with madshi's findings or with 2-3 other people that don't agree, but they also don't show why they don't agree with e.x. samples or screenshots (including the settings they used).

Especially when you write "tests for a few days now". Well, to be quite frank, IF I had so much time on my hands to do tests, I would not hesitate for even a second to provide a couple example shots to show it to everyone, so there actually is some discussion that will help everyone.

Last edited by iSunrise; 19th July 2015 at 19:27.
iSunrise is offline   Reply With Quote
Old 19th July 2015, 19:24   #31954  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by iSunrise View Post
If you disagree and you show samples, madshi will listen. I don't get why you invest countless hours in testing, yet, no screenshots to prove your point.

How do you expect madshi to react? Believe 20 other people that say A looks more satisfying and agree with madshi's findings or with 2-3 other people that don't agree, but they also don't show why they don't agree with e.x. samples or screenshots (including the settings they used).

Especially when you write "tests for a few days now". Well, to be quite frank, IF I had so much time on my hands to do tests, I would no hesitate a second to provide a couple example shots to show it to everyone, so there actually is some discussion that will help everyone.
Exactly.
madshi is offline   Reply With Quote
Old 19th July 2015, 20:45   #31955  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,788
Quote:
Originally Posted by Dogway View Post
-remove deinterlacing, software deinterlacing is never going to replace offline deinterlacing. Better let TV deinterlace real-time.
Its not software deinterlacing, its hardware deinterlacing in the GPU, which has an acceptable quality for real-time processing.
On top of that, output of interlaced material from a PC has all sorts of problems.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 19th July 2015, 22:51   #31956  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by Ver Greeneyes View Post
I think the problem has been around ever since the new windowed mode was introduced, I just never made the connection before. I see it on both my laptop (with an old AMD GPU, legacy drivers) and my desktop (with a GeForce GTX 580, latest drivers), but there's probably something about the way livestreamer connects with MPC-HC that causes it. I definitely don't see it on every stream though, so I think I'll have to wait for a 'low quality' stream to get a debug log. I'll also try it with smooth motion disabled in case it makes a difference.

Edit: Oh, and flush settings are |flush, flush & wait (sleep), don't flush, don't flush|, which I believe is the default. I have it set to present 8 frames in advance, with a CPU queue size of 48 and a GPU queue size of 24, and "use a separate device for presentation" is checked.
Those should be the default flush settings. For now I'd kindly ask you to postpone this bug until all the new bugs introduced by v0.88.17 are solved, if you don't mind. Otherwise it's just too much atm. I can handle only so many bug reports at a time.

Quote:
Originally Posted by James Freeman View Post
88.17 introduced it; 88.16 is fine.
Only when something on the screen besides the video (Stats menu, volume, time marks, etc...).
Ok, please try with v0.88.20.

Quote:
Originally Posted by Siso View Post
All kinds of panning shots are somehow problematic in the latest builds etc 0.16, 0.17, 0.18, 0.19. I'm on Dell ud2913wm @ 72 hz+reclock. Also I lowered my dpc latency a lot, around 40-50-60 nanoseconds.
You sure it occurs with v0.88.16?? Because the "dramatic" change that caused problems for most other users happened in v0.88.17. Please try to find out the exact build which introduced the problem for you. You can download old builds with the link from the first post in this thread.

Quote:
Originally Posted by mogli View Post
New path, yes, but I'm only testing FSE since I don't use windowed mode. (I restart MPC-HC after switching between D3D9/11.)

I reported the speed increase with v88.12. However I don't remember if it started earlier.

Note that D3D11 also about halves my presentation timings. Using 'separate device' has no effect on this at all, only on rendering.
Well, might be that the modified OSD logic doesn't properly measure the time the OSD drawing costs, I'm not sure right now.

Quote:
Originally Posted by Akeno View Post
The source I used actually has aliasing already in it. NNEDI3 miraculously anti-aliases the image and SuperRes brings back the aliasing. Anyone know why that is?
Quote:
Originally Posted by har3inger View Post
If the source has aliasing, presumably SuperRes is interpreting that aliasing as meaningful information and is trying to reproduce the lost aliasing in the final result.
Thanks for taking the time to make comparison screenshots. har3inger is correct, though. SuperRes works by trying to make sure that the upscaled image is a "fair representation" of the original source. If the source had aliasing artifacts and the upscale doesn't, SuperRes probably considers that a "degradation" and tries to make the upscaled image nearer to the original source, which will probably reintroduce the aliasing artifacts to a certain extent.

I suppose the proper solution for this would be to remove the aliasing artifacts before upscaling the image. AviSynth has some filters for that, but they're pretty slow, IIRC. Maybe madVR will get such a filter at some time in the future, but probably not soon.

Quote:
Originally Posted by nijiko View Post
MPEG2 deinterlacing is too SLOWLY (according to rendering time)
Quote:
Originally Posted by michkrol View Post
Please provide more information:
Do you actually get dropped frames?
What decoder are you using (software/DXVA/CUVID/QuickSync)?
What OS and player are you using?
What GPU and drivers (version) are you using?
A screenshot of the OSD would also be helpful.
^

Quote:
Originally Posted by Warner306 View Post
Using the test build, the performance of SuperRes has degraded to the point I can no longer run Strength 1.
Compared to which older build? v0.88.17 introduced a SuperRes anti-ringing filter, which costs some performance. So if you compare to e.g. v0.88.16, the newer builds are expected to perform a bit slower. However, there should be no big difference between v0.88.17 and v0.88.19.

Anyway, there may be room for further performance optimizations. For now we're trying to fine tune the algorithm, remove what's superfluous, set fixed values where it makes sense. Once the dust has settled, maybe some performance optimizations can be done.

Quote:
Originally Posted by KoD View Post
Hi, I experience lots of dropped frames after switching between fullscreen and windowed modes, the way I describe below:

What I do is this: start playback-> all is fine, go fullscreen -> everything is still fine, then go back to windowed mode -> all still fine -> go back to full screen -> now lots of frames dropped, it does not recover itself unless I pause the video, and then resume. With 0.88.12 it was enough to pause once, and then playback would be smooth again after resuming; with 0.88.19 once is often not enough, I have to pause twice. It looks like the render queue does not recover staying at 1-3 or 2-3, even though the decoder, subtitle and upload queues fill up to their normal stats. The present queue also ends up with the same fill status as the render queue.

Some details: I'm using MPC, with its internal filters for h264 playback of mkvs, it happens on both 8 bit and 10 bit content, irrespective of whether I use software or hardware decoding. Happens only when using D3D11 and fullscreen exclusive mode. If I use full screen windowed mode, or I use the D3D9 renderer, all is fine.

I happen to have a Sony TV which accepts 12 bit color input. When using D3D11 and fullscreen exclusive mode, the TV receives 12bit per channel input (I can see this by pressing the Info key on the remote).

Have not changed the graphics drivers since a long time ago, it's still version 347.25 on a GTX980 for me.
Is this a new problem with the newer madVR builds? Or what it "always" this way?

Quote:
Originally Posted by ryrynz View Post
I bothered to do a little further testing tonight on this issue I reported a month ago and came to post the exact same thing.. looks like I didn't need not bother..

Sometimes I've seen it recover while paused only to drop the queue to low values again once it's started playing. And yes it's generally when you do a "messy" (multiple switching, pausing etc) windowed to fullscreen switch.
So this is an "old" issue and was not caused by the recent changes in v0.88.17?

Quote:
Originally Posted by tFWo View Post
I'll be using this too. HQ is the source of most of the problems I have with Superres. There is a new problem when using this. Strength 1 is too strong with HQ turned off . Maybe add strength 0 that halves the strength.

"Radius" option helps only a little when HQ is on. Turning it higher than 0.75-0.80 does remove most of the artifacts, but it also softens the image considerably. Again I fail to find a purpose for Superres with a trade-off like that.

With HQ off, "radius" is less important. It just has to be just above 0.5 (i set it at 0.7 just to be sure). When it's set below 0.5 aliasing/pixelization appears.
Can you show a couple of screenshots which show why you prefer HQ off? Please post the original image (PNG is fine) together with the upscaled & SuperRes'ed results. The original image is important, so we can reproduce your results here, and maybe fine tune the algorithm. Thanks!

Quote:
Originally Posted by Nachbar View Post
I noticed my new 4K TV will not display anything above 235 or below 16 when it is set to Full Range. Set to limited I am now able to perceive those values. Should I set it to limited or full range in the driver and in madvr?
Also should I set LAV Video to PC, limited, or untouched? I think untouched is correct for now.
Should I also be using YCbCR instead of RGB?
Such questions are asked all the time in this thread, so I'm not going to go into any detail here. Makes no fun writing the same replies every couple of pages all over again.

Leave LAV at default values. Don't use YCbCr unless after extensive testing you find it works best, due to technical limitations of your TV. Whether you should set the GPU, TV and madVR to PC or TV levels is a complicated question that can't be explained in one short sentence. Anybody has a link to a guide that explains this?

Quote:
Originally Posted by leeperry View Post
TBH this release has completely killed SuperRes for me
Huh? This release re-introduced "HQ off" for you. I'm confused how that would kill SuperRes for you? Instead of saying "thank you" for adding a tweak *just for you*, you continue to whine, and you don't do screenshots, as I asked you to multiple times already. You're not very motivating atm.

Quote:
Originally Posted by leeperry View Post
And I wholeheartedly disagree that 2 passes at 1.0 look "pretty much" identical to 3@0.65 in .15 as the former looks way sharper and less detailed....
I've already told you that if that is your opinion, I want proof, in the form of screenshots. Put up or shut up!!
madshi is offline   Reply With Quote
Old 19th July 2015, 22:54   #31957  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
madVR v0.88.20 released

http://madshi.net/madVR.zip

Code:
* changed OSD rendering logic all over again
* added SuperRes "radius" option (only for testing purposes)
* removed SuperRes "use alternative color space" option
* replaced SuperRes strength+passes option with a new strength option
* added madTPG APIs "IsFseModeEnabled" and "En/DisableFseMode"
Since there have been a couple of users having problems with all kinds of weird stuttering issues, caused by the OSD rendering changes in v0.88.17, I've decided to change the OSD rendering logic all over again in this build. These are deep changes, once again, and might cause follow-up problems. So this might be another experimental build, introducing new bugs. On the other hand, I hope that at least some of those stuttering issues are resolved now?

Everyone who had *new* problems, introduced by v0.88.17, please test this new build and let me know if your problems are fixed.

Everyone who has "old" problems (which affect builds older than v0.88.17, too), please hold your horses for now. Allow me to fix all the new issues first, otherwise I'll get bugfix overload.
madshi is offline   Reply With Quote
Old 19th July 2015, 23:11   #31958  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 445
Quote:
Originally Posted by madshi View Post
Those should be the default flush settings. For now I'd kindly ask you to postpone this bug until all the new bugs introduced by v0.88.17 are solved, if you don't mind. Otherwise it's just too much atm. I can handle only so many bug reports at a time.
Sure, that's fine. I can just use the D3D11 path anyway.
Ver Greeneyes is offline   Reply With Quote
Old 19th July 2015, 23:35   #31959  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,203
Quote:
Originally Posted by madshi View Post
So this is an "old" issue and was not caused by the recent changes in v0.88.17?
Yeah probably as old as the d3d 11 implementation in MadVR.
ryrynz is offline   Reply With Quote
Old 19th July 2015, 23:47   #31960  |  Link
Akeno
Registered User
 
Join Date: Jul 2015
Location: Seattle, Washington
Posts: 53
New bug with the 88.20. Seems like the OSD is reporting incorrect render times. Render time is lower than what it was in previous updates with the exact same settings (I'm not using SuperRes). It reports even lower render times when I go from NNEDI3 16 -> 32 but the dropped frames and presentation glitches counter begin to rise.
Akeno is offline   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 18:54.


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