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, 14:51   #31941  |  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   #31942  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
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   #31943  |  Link
Dlget
Registered User
 
Join Date: Sep 2012
Posts: 53
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   #31944  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
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   #31945  |  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   #31946  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
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   #31947  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
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   #31948  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
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 offline   Reply With Quote
Old 19th July 2015, 22:51   #31949  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
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   #31950  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
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   #31951  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 447
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   #31952  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
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   #31953  |  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
Old 19th July 2015, 23:58   #31954  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by iSunrise View Post
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
It's 4 guys(or was it 6?) that got HQ forced and barely anyone reported on the 0.19 SR options IIRC so your "20 other people" seems pretty far stretched.

I tried yesterday late at night on my usual 720p material and this afternoon again on different kinds of SD material just to be sure that my impressions didn't change and then I saw that post that pretty much synthesized exactly what I saw so I thought I would +1 it, nothing more.

I also came to the conclusion this afternoon that sxbr+AS seem to look equally good(or even better?) than SR in .15 with 3@0.42 but I would need to finetune their strengths(sxbr75+AS 0.5 atm), madshi made clear that SR would take a route I'm not interested in so again I can either give up on SR altogether(as it's literalling been going downhill since .16 for me) or remain stuck in .15-land. I haven't really decided yet, yes it takes several test sessions on different kinds of material before making a decision.

If I had access to the script as a text file or could fire up SR from PotPlayer as a PS script, this wouldn't be much of a hassle but I do realize that madshi's work on mVR is already a gift, he's not too keen on sharing his work with the competition, he primarly codes mVR for his own use and he's already extremely kind to share it with us...so I need to adapt my needs to what he's willing to offer(and PQ is stellar anyway ).

Quote:
Originally Posted by madshi View Post
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.
Yes my bad where are my manners sorry, TYVM for taking the time to make the change . I sure would fancy the same kind of kludge to change the sxbr strength to be honest ^^

I wasn't able to use versions since .16 due to HQ SR being forced so I'm basically going from .15 to .19 and yes this new build is a total show stopper for me as far as SR is concerned, HQ or not.

Screenshots? I'm sure you did a whole bunch of them when deciding that HQ=off looks horrible to you? Or did you toggle it while playing movie content? My point is that for all I know screenshots wouldn't prove anything and I would waste hours looking at microscopic pixels differences. It really only matters in motion IMHO and the differences I'm seeing are not content dependent to the least. At the end of the day what matters if that SR looks good to you and that I can also keep on being stunned by mVR, I seem willing to give up on SR as our views towards it would appear to drastically diverge. No worries.

Quote:
Originally Posted by madshi View Post
I've already told you that if that is your opinion, I want proof, in the form of screenshots. Put up or shut up!!
Oh totally, I was only +1 another post so the guy wouldn't be alone in the middle of the ocean of posts here and considered to be a misfit of some kind.

Quote:
Originally Posted by madshi View Post
I hope that at least some of those stuttering issues are resolved now
I definitely got random stuttering while seeking with .19 in PotP that didn't occur with .15 on W7SP1/HD7850/13.12/8bit DX9, will try the new build then


Last edited by leeperry; 20th July 2015 at 02:10.
leeperry is offline   Reply With Quote
Old 20th July 2015, 00:13   #31955  |  Link
Nevilne
Registered User
 
Join Date: Aug 2010
Posts: 134
So you literally can't show any proof
Nevilne is offline   Reply With Quote
Old 20th July 2015, 01:23   #31956  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 447
madshi, I took debug logs for the 'repeated frames show very old frames' thing, comparing d3d9 and d3d11 windowed mode, though I don't know if they show anything. Just let me know when you have time to look at them.
Ver Greeneyes is offline   Reply With Quote
Old 20th July 2015, 01:23   #31957  |  Link
tFWo
Registered User
 
Join Date: Apr 2011
Posts: 24
Quote:
Originally Posted by madshi View Post
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!
I'm off on vacation for next two weeks so I'm doing this at the last moment before going.

original
http://www84.zippyshare.com/v/CDsDqi9P/file.html

hq strength 1 radius 0.70
http://abload.de/img/seventhhqjpjxy.png

nohq strength 1 radius 0.70
http://abload.de/img/seventhnohqaejzk.png

It's hard to compare because strength 1 for nohq is too strong.

As I said radius does help. But HQ still has that almost softer than original look with slight ringing around numbers. White is spilled into black area, black is spilled into white area.

NoHQ doesn't have that problem even on higher strengths. But as I said even strength 1 is too strong for my taste.
tFWo is offline   Reply With Quote
Old 20th July 2015, 01:42   #31958  |  Link
Deim0s
Registered User
 
Join Date: Jul 2012
Posts: 20
Quote:
Originally Posted by madshi View Post
Everyone who had *new* problems, introduced by v0.88.17, please test this new build and let me know if your problems are fixed.
I have problems with builds after 0.88.16.
Examples and dump below:
OSD (SD MPEG-2)
dump

OSD (720p - presentation glitches when step forward/backward)
dump

Win 7 SP1 Pro x64
ASUS GTX770 2Gb
ASUS VG278H 120 Hz
MPC-HC x64 latest nightly build
LAV x64 latest nightly build
Deim0s is offline   Reply With Quote
Old 20th July 2015, 02:37   #31959  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by Nevilne View Post
So you literally can't show any proof
I don't think you've been here on enough to know quite how Max's testing methodology works..

His super vision defies all screenshot proof justifying it. He sees things us mere mortals cannot.
ryrynz is offline   Reply With Quote
Old 20th July 2015, 02:48   #31960  |  Link
jewshawn2
Registered User
 
Join Date: Jul 2015
Posts: 3
madVR / Potplayer / OBS broken since v0.88.17

I am reporting a bug that was introduced since v0.88.17.

In order for OBS (Open Broadcaster Software) to capture video in Potplayer with madVR, you have to use "Game Capture" source. I was told by someone on the OBS forum that this uses OpenGL to capture video. And it is the only method to capture video with madVR as the renderer.

Since v0.88.17 video capture using OBS (both versions) and Potplayer causes unwatchable jittery/stuttering video. The video looks perfectly fine on screen. But the OBS capture window shows jittery video. v0.88.16 was the last release that worked fine.

The bug can be reproduce on both of my PCs using the default madVR settings and default PotPlayer settings. However, if I use a different video player like MPC-HC x64 or bsplayer with madVR the video capture in OBS is fine. But when I adjust volume level the OSD causes stuttering video in the capture window.

I don't expect this bug report to get a lot of attention since it's very specific but I still wanted to report it for documentation purposes. I hope other forums members can reproduce the bug and verify my claims.

These were the changes introduced to madVR, perhaps one of these changes broke functionality between madVR, Potplayer, and OBS:
v0.88.17
* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected

My setup:

madVR v0.88.17 thru v0.88.20

x64 bit Potplayer [1.6.55124] 2015/07/10

x64 OBS Multiplatform 0.11.1

x64 OBS Original 0.652b

x64 Win 7 / Nvidia 8800 GTS

Last edited by jewshawn2; 20th July 2015 at 11:42.
jewshawn2 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 19:55.


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