View Full Version : madVR - high quality video renderer (GPU assisted)
webs0r
6th April 2014, 01:18
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.
Give it a try and let me know how it works for you!
The new presentation path only works in Windows 8/8.1, or in Windows 7 with Aero/DesktopComposition enabled. You can detect which mode is used by looking at the debug OSD (Ctrl+J). The old windowed mode path shows a "backbuffer queue", the new path shows a "present queue". You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.
OK initially I installed this test package over a madVR version slightly older than v0.87.9 and then the player wouldn't connect madVR (fell back to EVR or something).
I installed v0.87.9, then put this package on top and it works.
Not sure if I accidentally did something wrong the first time, but just FYI if anyone has problems initially.
With my testing, the mode works fine, but I'll report some strange behaviour.
Setup: Win7, NV GTX680 user here (v331.65 driver)
Typically I've always been using windowed mode with no flushes, and have no issues.
Queues always full.
With the present frames in advance enabled:
Works fine, but if I obscure a large part of the video playback area with another window (Firefox), or even with madVRs own settings dialog, I notice the present queue drops from full to 1-3/8.
The render queue is affected as well.
It doesn't drop frames, until I moved the obscuring window away - then it starts dropping some frames slowly. The act of moving it away makes the queue state worse!
Pausing the video and unpausing restores all the queues.
I'm doing this with the player window maximised but not fullscreen.
madshi can you reproduce this or would you like logs?
ryrynz
6th April 2014, 01:32
Sounds like the same issue I had. Looked to be chrome which was in the background. I shut it down and queues were good but after restarting the player with chrome still not loaded the queues were low again. Might try disabling desktop composition n see what happens.
Anime Viewer
6th April 2014, 03:30
NNEDI3 doesn't seem to behave well with Smooth Motion enabled.
Without Smooth Motion I could set twice the neurons (ex:32) without dropped frames than I could with it enabled (ex:16).
With them both enabled watching two 720p videos of the same video format (h264,8 bit, 4:2:0-> NV12, 8 bit, 4:2:0) two very different results occurred with one (Akuma no Riddle episode 1) there were no dropped frames, but with the other (One Piece episode 638) it started dropping lots of frames right away.
Watching a 1080p video on my 1920x1080 screen with both NNEDI3 and Smooth Motion enabled it reported dropping lots of frames very quickly (with the movie resolution and target rectangle being identical NNEDI3 chroma upscaling should have been disabled). I changed the NNEDI3 to Jinc (which also should be disabled at that resolution) and the drops completely stopped. (Running with NNEDI3 enabled, and Smooth Motion disabled there were no dropped frames).
huhn
6th April 2014, 03:54
is your one piece ep maybe VFR or straight 29 fps? normally or at least i think one piece needs that. higher FPS = more work.
(with the movie resolution and target rectangle being identical NNEDI3 chroma upscaling should have been disabled)
a 1080p video/BD normally got a chroma resolution of 540p. are you sure nnedi3 wasn't used for chroma?
cyberbeing
6th April 2014, 04:09
Unfortunately, it appears that madVR 0.87.8 introduced a bug with NNEDI3 Chroma Doubling + Smoothmotion. Tested on my GTX 770 with new and old drivers.
Reset madVR to default settings
Enable Smooth Motion
Enable NNEDI3 Luma & Chroma Doubling
Open a small video in MPC-HC which triggers smooth motion (https://www.mediafire.com/?6192wf8w56bwbb7)
Either maximize the MPC-HC window or enter fullscreen
ALT+3 to have MPC-HC zoom to 200%
Result: Black flashing when viewed at 200%
I'll open a new issue on madshi's bug tracker after I wake up tomorrow.
Anime Viewer
6th April 2014, 05:34
is your one piece ep maybe VFR or straight 29 fps? normally or at least i think one piece needs that. higher FPS = more work.
a 1080p video/BD normally got a chroma resolution of 540p. are you sure nnedi3 wasn't used for chroma?
Now that you brought up fps I looked at the two videos from a frame rate comparison the one piece file is a slightly higher frame rate at 29.97 vs 23.97 for riddle.
By VFR you're referring to variable frame rate, correct?
One Piece 638 720p file stats:
Video: MPEG4 Video (H264) 1280x720 29.97fps [V: h264 high L4.0, yuv420p, 1280x720 [default]]
Audio: AAC 44100Hz stereo [A: Japanese [jpn] (aac, 44100 Hz, stereo) [default]]
Riddle 720p file stats:
Video: MPEG4 Video (H264) 1280x720 23.976fps [V: h264 high L4.1, yuv420p, 1280x720 [default]]
Audio: AAC 48000Hz stereo [A: Audio [jpn] (aac, 48000 Hz, stereo) [default]]
I just tossed a 480p One Piece episode 639, and the Smooth Motion NNEDI3 combination couldn't handle that either. (Even when I dropped the NNEDI3 neurons to the minimum 16). Once again the dropped frames was eliminated by either disabling smooth motion or switching to Jinc. Looks like fps may be more of a hindrance then resolution when it comes to what cripples NNEDI3 upscaling. To try to balance out the fps difference I tried using ReCock with both files, but that made it repeat a ton of frames and crippled the sound.
One Piece 639 480p file stats:
Video: MPEG4 Video (H264) 848x480 (247:139) 30.303fps [V: h264 main L3.1, yuv420p, 848x480 [default,forced]]
Audio: AAC 44100Hz stereo [A: aac, 44100 Hz, stereo [default,forced]]
The 1080p video had the following stats (perhaps it being 10-bit as opposed to 8-bit could be an issue):
Video: MPEG4 Video (H264) 1920x1080 23.976fps [V: H.264 (h264 high 10 L5.1, yuv420p10le, 1920x1080) [default]]
Audio: AAC 48000Hz 6ch [A: Japanese 5.1 AAC [jpn] (aac, 48000 Hz, 5.1) [default]]
Might NNEDI3 have a weakness when it comes to handling 10-bit files in perhaps a similar way to how hardware acceleration doesn't work with 10-bit files?
I'm guessing deintFps which is listed as framerate after deinterlacing in the rules coding (http://forum.doom9.org/showthread.php?p=1271417#post1271417) has to do with the videos frame rate as opposed to the displays playback frame rate because I tried to create the rule:
if (deintFps <= 30) "SM on"
else "SM off"
In "SM on" profile I set it to Smooth Motion on
In "SM off" profile I set it to Smooth Motion off
To try to tell it to when playing on a display that is capable of playing at 30 hz or less to turn Smooth Motion on, and that way if it is played on a display of 59hz or 60hz it will run with Smooth Motion off.
masshi is that something you might be able to add coding for some where down the road? (Perhaps call it something like "displayHz"). It might prove useful, and could be used for processing and scaling rules as well...
huhn
6th April 2014, 06:12
are you using ED? ED plus smoothmotion can be hard too.
29 fps is a lot hardwe then 23 fps.
about the 480p are you using nnedi3 with always and quadrupling, or is nnedi3 chroma doubling set to 2x?
what about vram?
10 bit doesn't matter to madvr, madvr stores everything in 16 bit so it real doesn't matter at all.
michkrol
6th April 2014, 09:11
I'm guessing deintFps which is listed as framerate after deinterlacing in the rules coding (http://forum.doom9.org/showthread.php?p=1271417#post1271417) has to do with the videos frame rate as opposed to the displays playback frame rate
Yes, just as it says. After deinterlace means you get 23/24/25fps for progressive and usually double that for interlaced video, so it's the number of frames per second that madVR has to actually process (scale, deband, etc.).
I tried to create the rule:
if (deintFps <= 30) "SM on"
else "SM off"
In "SM on" profile I set it to Smooth Motion on
In "SM off" profile I set it to Smooth Motion off
To try to tell it to when playing on a display that is capable of playing at 30 hz or less to turn Smooth Motion on, and that way if it is played on a display of 59hz or 60hz it will run with Smooth Motion off.
Wouldn't you normally want to disable SM for displays that are capable of running at the movie's framerate and enable it for displays capable of running only at 59/60Hz?
madshi is that something you might be able to add coding for some where down the road? (Perhaps call it something like "displayHz"). It might prove useful, and could be used for processing and scaling rules as well...
It's already there: 'refreshRate' is your current display refresh rate in Hz ;) Take note Windows' 59Hz is actually 59,94..Hz, so you might need to use > or < instead of = to detect it correctly.
--------------
@madshi Maybe it would be possible to add a boolean value for "smoothMotion" to the profiles' auto select rules, so we can easily check whether it's enabled or disabled (same value the OSD displays), especially since you can't (easily) check something like refreshrate/fps = integer, but you get options to only use SM if there would be judder.
StinDaWg
6th April 2014, 13:25
I'm having a strange issue with NNEDI image doubling on my Sapphire 7770. If set to 16 neurons, it makes my card give off an audible whine or electrical interference noise. It's not the fan, but the chip itself. GPU load is about 60%. With 32 neurons the noise completely goes away, gpu load is 91%. Nothing else makes my card do this, gaming, ect. Only NNEDI 16 neurons. Is there any explanation for this?
ryrynz
6th April 2014, 13:34
I'm having a strange issue with NNEDI image doubling on my Sapphire 7770. If set to 16 neurons, it makes my card give off an audible whine or electrical interference noise. It's not the fan, but the chip itself. GPU load is about 60%. With 32 neurons the noise completely goes away, gpu load is 91%. Nothing else makes my card do this, gaming, ect. Only NNEDI 16 neurons. Is there any explanation for this?
It's not NNEDI 16 neurons that's the issue, it's your card's coil noise. There's nothing you can do really but change the card, preferably a different manufacturer.
Other options include using nail polish or hot glue to fix the problem.
The best thing to do would be to get a recommendation from another user that owns a "quiet" card.
6233638
6th April 2014, 13:35
I'm having a strange issue with NNEDI image doubling on my Sapphire 7770. If set to 16 neurons, it makes my card give off an audible whine or electrical interference noise. It's not the fan, but the chip itself. GPU load is about 60%. With 32 neurons the noise completely goes away, gpu load is 91%. Nothing else makes my card do this, gaming, ect. Only NNEDI 16 neurons. Is there any explanation for this?Sounds like load-induced coil whine.
http://www.youtube.com/watch?v=HP73edpQwgc#t=0m07s
It's not that madVR is causing this to happen, it's just that those specific settings are putting a load on your GPU that happens to have coil whine.
annovif
6th April 2014, 13:45
Hello everybody, can i know what kind of ATI i have to buy to set Needi 3 256 neurons with bluray? 270-280-280x-290-290x ? Or do you think i have to buy an nvidia now?
Thank you, Fabio
flashmozzg
6th April 2014, 13:53
Hello everybody, can i know what kind of ATI i have to buy to set Needi 3 256 neurons with bluray? 270-280-280x-290-290x ? Or do you think i have to buy an nvidia now?
Thank you, Fabio
By bluray you mean 1080p? And what is your target resolution? If you going to watch it on 1080p display nnedi won't be even used(or needed).
Werewolfy
6th April 2014, 14:09
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.
Give it a try and let me know how it works for you!
The new presentation path only works in Windows 8/8.1, or in Windows 7 with Aero/DesktopComposition enabled. You can detect which mode is used by looking at the debug OSD (Ctrl+J). The old windowed mode path shows a "backbuffer queue", the new path shows a "present queue". You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.
Overlay mode is broken for me too but the new Windowed mode seems to work just fine, I don't see any issues for now.
StinDaWg
6th April 2014, 14:38
It's not NNEDI 16 neurons that's the issue, it's your card's coil noise. There's nothing you can do really but change the card, preferably a different manufacturer.
Other options include using nail polish or hot glue to fix the problem.
The best thing to do would be to get a recommendation from another user that owns a "quiet" card.
It's just weird that only NNEDI 16 does this, regardless of gpu load. Some videos with N16 will stress the card to near 100% and others only 30% and yet both make the card whine/buzz. Switching to 32 or higher stops it every time.
I'm thinking of getting an ASUS DirectCU II model, those as well as MSI TWIN FROZR IV seem to have the lowest noise levels in professional reviews.
QBhd
6th April 2014, 15:19
Loving my ASUS Direct CU II R9 270x... it's very quiet, I have to physically get up from the couch and go over to the PC (it's only about 8' away and in the open) to hear the faintest of fan noise. And I have madVR profiles that push my GPU to over 90% for all video formats I watch.
I will add this disclaimer, it's in a HAF 932 with 3x230mm fans and I also have an H80i sitting on the CPU... so it's a very cool case, but any noise can be easily heard due to it's open design nature.
QB
Anime Viewer
6th April 2014, 17:59
It's already there: 'refreshRate' is your current display refresh rate in Hz ;) Take note Windows' 59Hz is actually 59,94..Hz, so you might need to use > or < instead of = to detect it correctly.
Thanks for pointing that out. Don't know how I missed the "displayMode.x/y, refreshRate display mode information" listing there.
I tried creating the rule:
if (refreshRate <= 31) "SM on"
else "SM off"
with SM on being a profile with Smooth Motion on, and SM off being a profile with Smooth Motion off, but it doesn't seem to work as Smooth Motion never turn on when a video with a frame rate of 29.97 is running on a monitor (tv) that is set to run at 30hz. That makes me think that perhaps I need to include "displayMode.x/y," in the rule. Anyone know what's supposed to replace the ".x/y"?
Wouldn't you normally want to disable SM for displays that are capable of running at the movie's framerate and enable it for displays capable of running only at 59/60Hz?
When Smooth Motion (along with NNEDI3 chroma upscaling) is running on the 59hz/60hz display (notebook screen) it reports dropped frames, but with Smooth Motion off it doesn't. Therefore I thought it would be a good idea to create a profile/rule where it shuts off Smooth Motion when running on the notebook screen, but turns it on when running on the tv screen.
are you using ED? ED plus smoothmotion can be hard too.
29 fps is a lot hardwe then 23 fps.
about the 480p are you using nnedi3 with always and quadrupling, or is nnedi3 chroma doubling set to 2x?
what about vram?
I am running with Error Diffusion - option 1 selected for dithering. I'll experiment with using the two dithering options as opposed to Error Diffusion in combination with SM and NNEDI3 to see if that makes a difference, but if it does I'll probably decide to use Jinc with Smooth Motion on and Error Diffusion on as opposed to NNEDI3 at 16 neurons with Error Diffusion (and/or Smooth Motion) off.
I'm not using any of the NNEDI3 doubling (or quad) features, because as soon as I do (even with chroma upscaling only set to 16 neurons, and Smooth Motion disabled) it drops frames right at the start of playback. That and the general consensus on this board seems to be that its better to use (more noticeable benefits) to use chroma upscaling compared to chroma doubling.
As for VRam my Nvidia GeForce GTX 680M has 12GB VRam (4096 MB GDDR 5 dedicated, and 8137 MB system shared), so I doubt that would be bottle-necking in this situation.
Stereodude
6th April 2014, 19:23
By bluray you mean 1080p? And what is your target resolution? If you going to watch it on 1080p display nnedi won't be even used(or needed).The chroma has to be resized for 1920x1080 playback of FHD content, so that's not entirely true.
Mangix
6th April 2014, 19:28
It's just weird that only NNEDI 16 does this, regardless of gpu load. Some videos with N16 will stress the card to near 100% and others only 30% and yet both make the card whine/buzz. Switching to 32 or higher stops it every time.
I'm thinking of getting an ASUS DirectCU II model, those as well as MSI TWIN FROZR IV seem to have the lowest noise levels in professional reviews.
NNEDI3 is implemented through OpenCL which more or less uses the compute units directly. Which kind of means that it's using the GPU in a more direct fashion.
michkrol
6th April 2014, 19:41
It's just weird that only NNEDI 16 does this, regardless of gpu load. Some videos with N16 will stress the card to near 100% and others only 30% and yet both make the card whine/buzz. Switching to 32 or higher stops it every time.
Maybe it's the power state/frequency it's in while NNEDI works? Still, probably not much can be done in software to fix this.
Thanks for pointing that out. Don't know how I missed the "displayMode.x/y, refreshRate display mode information" listing there.
I tried creating the rule:
if (refreshRate <= 31) "SM on"
else "SM off"
with SM on being a profile with Smooth Motion on, and SM off being a profile with Smooth Motion off, but it doesn't seem to work as Smooth Motion never turn on when a video with a frame rate of 29.97 is running on a monitor (tv) that is set to run at 30hz. That makes me think that perhaps I need to include "displayMode.x/y," in the rule. Anyone know what's supposed to replace the ".x/y"?
As for the smooth motion not being enabled, check OSD to see what refresh rate madVR detects, maybe it's close enough to the movie's fps to disable SM, unless you have it set to 'always'. Also check whether correct profile is loaded - after starting playback open settings and see which profile is bolded or just make the "SM on" first by drag&drop.
Your rules should work. For the resolution you use either x or y for horizonal or vertical resolution respectively, so to check if horizontal (x) dimension is 1920 use:
if (displayMode.x = 1920) "fhd tv" else "notebook"
When Smooth Motion (along with NNEDI3 chroma upscaling) is running on the 59hz/60hz display (notebook screen) it reports dropped frames, but with Smooth Motion off it doesn't. Therefore I thought it would be a good idea to create a profile/rule where it shuts off Smooth Motion when running on the notebook screen, but turns it on when running on the tv screen.
Since it's a notebook are you sure it's not throttled for some reason, lowering your performance? Are you sure you're using the nVidia's GPU and not the Intel one or both somehow? Your GPU is quite powerful so it should be able to handle those settings, probably even with screen bigger than 1920x1080.
You can check you GPU usage with GPU-Z (free download) to make sure which GPU is used.
the general consensus on this board seems to be that its better to use (more noticeable benefits) to use chroma upscaling compared to chroma doubling.
Actually it's more like luma doubling > chroma upscaling > chroma doubling, but that's for SD content. You results will vary greatly depending on your source and target resolution (and many other things).
For HD content I personally prefer smooth motion over NNEDI chroma upscaling on my 60Hz display, but I am limited by the performance of my Intel HD4000 right now ;)
madshi
6th April 2014, 20:07
Replies to your posts coming tomorrow. Thanks for the feedback about the test build so far.
Ok, Overlay is broken, please ignore that, that's an easy fix. What I'd like to know is whether the new windowed rendering mode is working better, the same, or worse for you? If it's worse, please be as specific as possible. I'd like to enable the new mode by default for the next build (after doing fixes, if necessary), if it works better for the majority of users (or at least not worse). Rendering times are not un-interesting, but really important is if playback is more reliable/stable with the new mode or not. E.g. Smooth Motion FRC working with the new mode, but stuttering with the old mode is a "good" test result. If the new mode clearly works worse for you, please let me know that, too. I'm mostly interested in playback stability/reliability. Possibly cosmetical problems of the new rendering mode are also worth mentioning, but less important.
aufkrawall
6th April 2014, 21:12
Results of new windowed mode seem totally comparable to FSE for me.
I have pretty much the same GPU usage with both, old windowed mode uses less ressources (since there are no frames rendered ahead, I guess).
No problems with FRC, NNEDI3 etc. with new windowed mode.
I was hoping for a better seekbar in FSE, but now this is redundant with new windowed mode. :)
trip_let
6th April 2014, 21:37
Results of new windowed mode seem totally comparable to FSE for me.
I have pretty much the same GPU usage with both, old windowed mode uses less ressources (since there are no frames rendered ahead, I guess).
No problems with FRC, NNEDI3 etc. with new windowed mode.
I was hoping for a better seekbar in FSE, but now this is redundant with new windowed mode. :)
I can't remember using old windowed mode in a while, but the above is about what I've seen too.
Rendering times are pretty much the same after they stabilize between new windowed and FSE.
dansrfe
6th April 2014, 22:49
@madshi
There is an issue with videoLUTs using windowed mode: http://bugs.madshi.net/view.php?id=124
seiyafan
6th April 2014, 23:55
I had a 290x and it could only do 64 neurons doubling from 1080 to 1440, so if you want to do 256 neurons, better wait for 490x, I doubt 390x can even handle it. :D
p.s. or wait till AMD fixed the interop issue.
aufkrawall
7th April 2014, 00:06
How is your GPU usage with NNEDI3 on AMD?
Does it come near to 100% when it's getting to slow?
johnniedoo
7th April 2014, 02:09
I have been updating builds with MPC BE and MADvr on my AMD FX8120 , Sapphire 7950 OC and trying NNEDI3 w/16,32, 64, etc or jinc 3tap to check frame drops and stability for all videos , either virtual dvd iso mpeg2s or streaming videos in many formats. I mostly read posts from nvidia gpu users and get confused as to which features are better for AMD or which just do not work with the catalyst drivers, i am also up to date with the most current CCC driver versions beta release 14.3 as of today.
I just noticed that when i use NNEDI3 with SM enabled i can go up to 128 neurons and notice no frame drops but as soon as i disable SM the frames begin to drop off very quickly. I had to stay with jinc 3tap up till the last MADvr or i got frame drops even with SM enabled. GPU usage is still OK either way.
I get good playback using Jinc 3tap and do not really notice much benefit to using NNEDI3 with 16 to 128neurons. I tried to use image doubling but that really taxes the gpu up to 100% and do not see any improvement in what i watch , also temps go up immediately
I keep checking the stats and refresh them after each change in MADvr as I go along to see which will be best and most efficient for my machines and interests. I appreciate all the great information i get from reading these posts only trying to keep track as to what is working or not with AMD vs nvidia gets a bit confusing.
John
seiyafan
7th April 2014, 04:52
Well, because all the movies I watch were about 24 fps, so I need to keep rendering time above approx. 41 ms. But for 60 fps, the frame dropping threshold is 16 ms. I think on my 290x, 16 neurons gets ~30% GPU utilization, however rendering time is above 20 ms (that's with everything in the lowest setting, debanding and ED are disabled and so on), so there is no way not to drop frame no matter what. This is for 1080 to 1440. 720 to 1080 has rendering time in the high 10's.
seiyafan
7th April 2014, 04:55
I get good playback using Jinc 3tap and do not really notice much benefit to using NNEDI3 with 16 to 128neurons. I tried to use image doubling but that really taxes the gpu up to 100% and do not see any improvement in what i watch
John
Actually, it's about not seeing things.
p.s. someone told me this earlier, I thought this is a very deep sentence, hence want to share it with you.
markanini
7th April 2014, 05:08
I have been updating builds with MPC BE and MADvr on my AMD FX8120 , Sapphire 7950 OC and trying NNEDI3 w/16,32, 64, etc or jinc 3tap to check frame drops and stability for all videos , either virtual dvd iso mpeg2s or streaming videos in many formats. I mostly read posts from nvidia gpu users and get confused as to which features are better for AMD or which just do not work with the catalyst drivers, i am also up to date with the most current CCC driver versions beta release 14.3 as of today.
I just noticed that when i use NNEDI3 with SM enabled i can go up to 128 neurons and notice no frame drops but as soon as i disable SM the frames begin to drop off very quickly. I had to stay with jinc 3tap up till the last MADvr or i got frame drops even with SM enabled. GPU usage is still OK either way.
I get good playback using Jinc 3tap and do not really notice much benefit to using NNEDI3 with 16 to 128neurons. I tried to use image doubling but that really taxes the gpu up to 100% and do not see any improvement in what i watch , also temps go up immediately
I keep checking the stats and refresh them after each change in MADvr as I go along to see which will be best and most efficient for my machines and interests. I appreciate all the great information i get from reading these posts only trying to keep track as to what is working or not with AMD vs nvidia gets a bit confusing.
John
What's the source resolution and display resolution? If you have you're watching 1080 video on a 1080 display the no scaling is taking place.
Asmodian
7th April 2014, 05:37
There would still be scaling for the chroma unless watching a 4:4:4 or RGB video.
QBhd
7th April 2014, 06:04
One thing I have noticed about trying to tell the differences between algorithms... watching stills/frozen frames/same scene over and over doesn't seem to help. But I DO notice the differences if I watch for extended periods of time. It's more about NOT noticing things.
@seiyafan:
I'm glad my ramblings found an audience :)
QB
leeperry
7th April 2014, 06:44
I'd gladly try the new build but I don't have Aero enabled and AMD GPU's can't do overlay.
How is your GPU usage with NNEDI3 on AMD?
Does it come near to 100% when it's getting too slow?
Yeah, that's also what I was thinking about as it might very well be that the interop lag doesn't matter (all that) much after all..at least with 24<>30fps content. We might be overloading the GPU before the effects of the interop lag would even matter(at least on Haswell 3.0).
madshi
7th April 2014, 09:29
It actually solves my issues, wonderful. It brings (me) better performances than FSE while suppressing the UI lag.
Cool. How does it compare to the old windowed mode?
Madshi, any idea's what might be hampering FSE mode in comparison to the new windowed mode at least in John's case?
There has been a number of posts between John and me about his madVR problems in this thread. If you want to know that, just look back and read them.
regular Windowed Mode seems to be working fine.
It did not solve the issue I had where certain things changing the video LUT during playback (e.g. f.lux (http://justgetflux.com/) set to a 60 minute transition) would cause it to drop frames though, which only FSE manages to avoid.
Ok. So basically you don't see any difference worth mentioning between old and new windowed mode?
Btw, please check the bug tracker, it's waiting for your feedback. Don't you get email notifications from the tracker?
the new windowed mode in full screen on my HD4000/Windows 7 PC using MPC-BE, there's lowish render and present queues (f.lux disabled) 2 or 3-4/8 and 5-6/8, simply pausing video and pressing play brings them both up to 7-8/8 where they remain rock solid.
Strange, I don't see that here. What happens if you increase the GPU queue sizes?
Is it normal that the queues get reloaded when going from windowed to full screen windowed mode?
Yes.
Is there any way you could recompile it with a less exotic VC++ runtime please?
The tool wasn't really meant for users, it was meant for AMD support.
I works, even better than the regular windowed mode, and faster.
Better how?
Very good job. On my system, the new windowed mode is definitely faster. Watching a 720p 23.976fps movie I get an average of 0.06ms and max stats 0.09ms with the new windowed mode path. After enabling (and restarting the player and the movie to make it comparable) the old windowed mode I get present times of 0.10ms and 0.11/0.12ms. Nice improvement. Stats also seem more stable, but don't take that as granted, just an observation by looking at the stats for several seconds.
Ok, thx. From what you're writing it seems the old windowed mode worked just fine for you, too, without any frame drops or other glitches? So you can only see an improvement in the OSD stats?
There seems to be a bug when disabling and re-enabling the "present several frames in advance" checkbox. At least on my system the renderer comes to a complete halt and only shows a still picture and video doesn't advance anymore (even though audio continues in the background). That's 100% reproducible, tried MPC-HC and PotPlayer.
Does this happen both when disabling and enabling that option? Or only when enabling the checkbox?
smooth motion seems to like this new windowed mode better than the old one on my Intel HD4000. I used to get some kind of judder in windowed (with SM), that's gone with the new mode. [...] Overall it works as good or better than the old mode for me.
Great - that's what I wanted to hear! I know several users had problems with smooth motion with the old windowed mode.
New windowed test works fine here. I still need to use FSE though, since sometimes the desktop composition stays stuck in a previous Hz which causes massive frame drops.
You could probably fix this by upgrading to Windows 8.
@madshi. On the new test build, i get the message "madvr reports: -creating Direct3D device failed (8876086c)"when i enable windowed overlay. I'm running windows 8.1 x64 with a i5-3470 and a gtx 660 with 8gb RAM.
It's a test build for windowed mode, so it doesn't matter much whether overlay mode is broken or not. I'm interested in how the old vs new windowed mode compares for you?
When switching off overlay, it works but with vsync issues, which I didn't notice in the latest stable release.
Which OS are you using? Aero enabled or disabled? Can you describe the vsync issues you're having? You mean you have tearing? Or do you mean something else? And do these issues go away if you disable the "present several frames in advance" option in the madVR windowed mode settings section?
Is it possible to create a profil in madvr that takes the bit rate of the video in consideration?
No, because madVR doesn't know the bitrate.
New windowed mode works well here with every sample I got. I will definitely keep using it as long as no issues appear.
Does it work better than the old mode?
Visually unpleasing black flashes with madVRwindowedTest when resizing the video window, though I guess something like that is necessary side-effect of presenting in advance? If you could somehow mask what I assume is madVR flushing the present queue on resize, that would be nice.
Tried, but failed. At this point I don't think I can fix that, unfortunately. But I don't find it too much of a problem, to be honest. I think the Overlay resizing artifacts (although improved in recent builds) are uglier...
Same results as everyone else with the new test build, overlay broken but presenting frames in advance window mode finally 0 dropped frames over a 42 minute episode, never seen that before. Madvr was also using ivtc with 0 cadence breaks which is more impressive.
Cadence breaks should not depend on the presentation mode (old vs new windowed mode), I think. Have you been using windowed mode in the past? You're not using FSE mode? And your impression is that the new windowed mode works better, correct?
Desktop Composition was quite improved with Windows 8, I've personally encountered quite a few issues with the Windows 7 composition mode (which can be solved by restarting the compositor) that just went away when testing on Windows 8 instead.
Yes, I'm seeing the same thing here. Basically desktop composition seems to work exactly as it's supposed to work in Windows 8 which wasn't always the case in Windows 7. When I originally heard that desktop composition couldn't be disabled in Windows 8, anymore, I was seriously annoyed. Not so, anymore. I never felt any need for disabling desktop composition in Windows 8 yet.
So far its worked well in my testing on single screens, and when displaying on multiple monitors (notebook screen and tv) if I use an HDMI cable directly between them.
Similar to the old windowed mode or better than the old mode?
However when I try to use Intel Widi/Miracast it drops frames quite quickly in both extend and duplicate modes whenever its set to present frames in advance (regardless of if its one or sixteen). I'll continue to experiment, and see if I can find a workaround for Widi/Miracast that doesn't involve shutting off the presenting frames in advance feature. Edit: Duplicate mode starts dropping them right at the start of the video, but Extend mode seems to go just short of 1 minute before it starts dropping frames.
(I was hoping the frames in advance feature might eliminate the issue of tearing on secondary monitors when using duplicate mode when using direct HDMI cables, but it looks like it unfortunately still exists).
These issues are probably not fixable from my side of things.
Using windows 8.1, I seem to be getting slightly better performance than FSE mode with this build! Although, only marginally better by .20-40 ms.
Checking and unchecking 'use a separate device for presentation' didn't seem to affect performance either way, so leaving that disabled.
Bumped windowed mode 'frames in advance' to 16, so queues are respectfully 24/20/16. Queues remained full, didn't receive any dropped frames except when starting the playback and going fullscreen.
I didn't notice any visual glitches with smooth motion enabled. I'm loving the new build and windowed mode, just for the performance and a responsive seek bar!
Sounds good. But how does it compare to the old windowed mode? That's the key question for me.
Is there any specific advantage to FSE that it should be used instead of windowed mode? I also do not have 'windowed overlay' enabled. Is there any advantage to enabling that option?
FSE mode should bring even more reliability and protection from frame drops. But if you have perfect playback with windowed mode, there's no need for FSE mode, really, at least not atm. Overlay is just another rendering mode, which has advantages and disadvantages. Again: If you have perfect playback with windowed mode, no need to use anything else.
@madshi: With new windowed mode, either with SM FRC enabled or disabled madVR draw 60fps. I guess it's expected? Before without SM it was just drawing at movie framerat IIRC.
Yes, with the new windowed mode, madVR presents 60fps. It only renders as many frames as necessary, though, so rendering performance shouldn't suffer (much). So e.g. with 24fps@60Hz with SM FRC turned off, madVR renders 24fps but presents 60fps, which means that some rendered frames may be presented multiple times. The "present several frames in advance" feature requires madVR to do one D3D9->Present() call per VSync refresh rate. Both in windowed and FSE mode.
With my testing, the mode works fine, but I'll report some strange behaviour.
Setup: Win7, NV GTX680 user here (v331.65 driver)
Typically I've always been using windowed mode with no flushes, and have no issues.
Queues always full.
With the present frames in advance enabled:
Works fine, but if I obscure a large part of the video playback area with another window (Firefox), or even with madVRs own settings dialog, I notice the present queue drops from full to 1-3/8.
The render queue is affected as well.
It doesn't drop frames, until I moved the obscuring window away - then it starts dropping some frames slowly. The act of moving it away makes the queue state worse!
Pausing the video and unpausing restores all the queues.
I can't reproduce this problem with my AMD. Haven't tested Intel and nVidia yet.
Could this be Windows 7 specific? Does everyone who uses Windows 7 have the same problem?
Sounds like the same issue I had. Looked to be chrome which was in the background. I shut it down and queues were good but after restarting the player with chrome still not loaded the queues were low again. Might try disabling desktop composition n see what happens.
If you disable desktop composition the new windowed mode will be disabled by madVR, too. It requires desktop composition.
Maybe it would be possible to add a boolean value for "smoothMotion" to the profiles' auto select rules, so we can easily check whether it's enabled or disabled
Possible, but I'm a bit afraid of profiles influencing each other. E.g. one rule set activating smooth motion FRC, another rule set reacting to that and turning something else off, which could again result in SM FRC being turned off, which then [...]. In theory this could result in profiles constantly switching back and forth all the time.
What purpose would you use a "smoothMotion" boolean value for? Which other settings would you change if that value is true or false? The performance hit of smoothMotion FRC is not *that* big, so I wonder if such a profile boolean is really of any practical use.
Hello everybody, can i know what kind of ATI i have to buy to set Needi 3 256 neurons with bluray?
For chroma upsampling or luma doubling or what? In any case, I'm not sure if any of today's GPUs can do that. NNEDI3 performance is more or less proportional to the neuron count. Which means that 256 neurons cost almost 16x as much performance as 16 neurons. Maybe for chroma upscaling 256 neurons could work with the fastest of today's GPUs, but I've not tested it, so I'm not sure. I don't think the benefit is high enough for chroma upscaling. I think 32 or 64 neurons is the max that is useful for chroma upscaling. But that's just my personal opinion, of course.
the new Windowed mode seems to work just fine, I don't see any issues for now.
Do you see any improvements over the old mode? Or do both work equally fine for you with no differences worth mentioning?
Results of new windowed mode seem totally comparable to FSE for me.
I have pretty much the same GPU usage with both, old windowed mode uses less ressources (since there are no frames rendered ahead, I guess).
No problems with FRC, NNEDI3 etc. with new windowed mode.
I was hoping for a better seekbar in FSE, but now this is redundant with new windowed mode. :)
So you're saying the old windowed mode used less resources. Which means is worked better for you?
I'm not sure why so many users report overlay issues or compare to FSE mode. The key question is: Is the new windowed mode better than the old windowed one? Or is it identical or worse? Everything else doesn't matter.
I can't remember using old windowed mode in a while, but the above is about what I've seen too.
Rendering times are pretty much the same after they stabilize between new windowed and FSE.
How does the old windowed mode compare to the new one on your PC? That's the one and only thing I would like to know.
@madshi
There is an issue with videoLUTs using windowed mode: http://bugs.madshi.net/view.php?id=124
Yes, I know. I get email notifications about every single change in the bug tracker, there's no need for you to post links to it here.
However, are you aware that you have 3 open bugs in the bug tracker which wait for a reply from you?
6233638
7th April 2014, 09:39
Ok. So basically you don't see any difference worth mentioning between old and new windowed mode?I don't, but I haven't noticed any problems with it either - though I haven't actually compared rendering times.
Btw, please check the bug tracker, it's waiting for your feedback. Don't you get email notifications from the tracker?I uploaded a new set of logs yesterday.
madshi
7th April 2014, 09:41
I uploaded a new set of logs yesterday.
Oh, missed that, thanks.
michkrol
7th April 2014, 10:21
What purpose would you use a "smoothMotion" boolean value for? Which other settings would you change if that value is true or false? The performance hit of smoothMotion FRC is not *that* big, so I wonder if such a profile boolean is really of any practical use.
I wanted to have error diffusion on my Intel HD4000, as it can barely manage it, but it looks like I'd need to sacrifice scaling quality in addition to smooth motion for this to work, so it's a no-go anyway.
Turns out I also get some random tearing-like artifacts every few seconds with error diffusion, but that's probably because of the GPU/memory being oversaturated, so I don't consider it as a bug and won't pursue this farther. It's high time I've gotten a "real" GPU it seems.
As always, thanks for your hard work and dedication.
ryrynz
7th April 2014, 10:34
Strange, I don't see that here. What happens if you increase the GPU queue sizes?
Doesn't change a thing. I found disabling desktop composition also disables the new path. No problems with the queues in FSE mode.
When I play in full screen windowed the render queue just sits on 1-3/16 as soon I pause the render queue jumps up to 0-16/16, then after pressing play, the queues just fill up normally.
madshi
7th April 2014, 10:43
When I play in full screen windowed the render queue just sits on 1-3/16 as soon I pause the render queue jumps up to 0-16/16, then after pressing play, the queues just fill up normally.
Can I please have a log from this? Let it play for 10 seconds with 1-3/16, then pause, then let it play until the queues are full. Then close. Thanks.
madshi
7th April 2014, 10:58
Here's a new test build with fixed Overlay and one very small presentation improvement for the new windowed mode:
http://madshi.net/madVRwindowedTest2.rar
@ryrynz, does this one fix the problem? If not, please create a log, as described above, thanks.
John Carmack
7th April 2014, 11:01
Cool. How does it compare to the old windowed mode?
See for yourself:
http://t.imgbox.com/eSpyFVqf.jpg (http://imgbox.com/eSpyFVqf)
Siso
7th April 2014, 11:02
Regarding the new windowed mode, the render queue, goes up and down something like if it is set to 5-6, it goes 4-6, every 3-4 seconds, with the old windowed mode it doesn't happen. The rendering times are very close to FSE :)
Just saw the new build, with the new test build2 render queue is stable here, getting one presentation glitch around 1 min after playback tho, sometimes goin' in fullscreen results in 2-6 presentation glitches.
ryrynz
7th April 2014, 11:19
@ryrynz, does this one fix the problem? If not, please create a log, as described above, thanks.
Fixed. :)
nikola
7th April 2014, 12:59
Which OS are you using? Aero enabled or disabled? Can you describe the vsync issues you're having? You mean you have tearing? Or do you mean something else? And do these issues go away if you disable the "present several frames in advance" option in the madVR windowed mode settings section?
Windows 7. Aero enabled. Tearing, yes. Haven't tested disabling that option, but I'm happy to report that with the latest test release it's working correctly, no tearing, both in overlay and non-overlay mode.
Another question: On madshi.net, do you happen to host a text file with just the latest non-test release version number in it? If not, may I ask if it's possible that you place it somewhere? e.g. http://madshi.net/madvr-version.txt
Anime Viewer
7th April 2014, 14:14
As for the smooth motion not being enabled, check OSD to see what refresh rate madVR detects, maybe it's close enough to the movie's fps to disable SM, unless you have it set to 'always'. Also check whether correct profile is loaded - after starting playback open settings and see which profile is bolded or just make the "SM on" first by drag&drop.
Your rules should work. For the resolution you use either x or y for horizonal or vertical resolution respectively, so to check if horizontal (x) dimension is 1920 use:
if (displayMode.x = 1920) "fhd tv" else "notebook"
Since it's a notebook are you sure it's not throttled for some reason, lowering your performance? Are you sure you're using the nVidia's GPU and not the Intel one or both somehow? Your GPU is quite powerful so it should be able to handle those settings, probably even with screen bigger than 1920x1080.
Actually it's more like luma doubling > chroma upscaling > chroma doubling, but that's for SD content. You results will vary greatly depending on your source and target resolution (and many other things).
For HD content I personally prefer smooth motion over NNEDI chroma upscaling on my 60Hz display, but I am limited by the performance of my Intel HD4000 right now ;)
I'll do some experimenting with luma doubling with SD content later, and see how noticable it is to me. Perhaps I'll test with a combination of NNEDI3 doubling and Jinc for the upscaling in SD content (if that sort of combination functions), and see how well that works compared to NNEDI3 for all three.
The rules was working as confirmed by what was bold in madVR's settings while the video was playing. Initially it was set to use only if there would be jitter without it, but I changed that to the "of if it is an exact match for the display rate" option. Odd thing was even with that checked it didn't turn on, and in the OSD for the video I was testing it reported the display 23.97207 and the movie 23.976 I'm not sure why it wasn't turning it on there. I could force it on with the "always" checked, but it madVR doesn't think it needs to be on then I'll trust its judgment. There is no benefit to forcing it "always" on, correct?
Another slightly odd thing was that that was with the direct HDMI cable connecting the notebook. When I used Intel Widi/Miracast instead of the direct HDMI with the same madVR settings, and the same video it turned Smooth Motion on.
I'm 99% sure its using the Nvidia GPU because both because its set in Nvidia control panel for the renamed mpc-hc2.exe, and because of the forced registry string madasi had me put it in registry and its results compared to when the Intel is forced in the registry. Power settings are at maximum performance while plugged in, so its not throttling the GPU there.
I'll try testing with GPU-z later.
Similar to the old windowed mode or better than the old mode?
These issues are probably not fixable from my side of things.
I vote for better than the old mode. While it reported dropping ~10 frames per second with the Intel Widi/Mircast mode I didn't see (or hear) any issues while watching (aside from glitches that have always existed with WiDi/Miracast and have as far as I know nothing to do with madvr or mpc). I suspect I don't see any issue even though its dropping frames thanks to the 16 frames in advance setting. I suspect the 16 frames in advance is canceling out the 10 dropped frames either that, or the reports of dropped frames is incorrect. Regardless it doesn't matter its not something I expected to be fixable from your end. I prefer to use a direct HDMI cable from the notebook as opposed to the Widi/Miracast when watching videos, and don't run with the widi unless I want to run run a game in duplicated mode (because the widi duplicate doesn't show taring which normally occurs when systems are running in duplicate mode with straight HDMI).
I haven't tested the new Test2 windowed mode, but I will after work today, and if I feel there is anything worth mentioning I'll do so then.
dansrfe
7th April 2014, 17:29
Yes, I know. I get email notifications about every single change in the bug tracker, there's no need for you to post links to it here.
However, are you aware that you have 3 open bugs in the bug tracker which wait for a reply from you?
My apologies. :o I've replied to the 3 other bugs.
MokrySedeS
7th April 2014, 17:49
Old path never caused me any problems so all I can compare is performance.
With smooth motion disabled, new path is slightly faster, but with SM enabled is a lot slower. OSD comparison here: http://i61.tinypic.com/2qjkbhu.png
But then again my gpu is so crappy that I have to dumb madVR down pretty much all the way to get smooth playback (bilinear resizing, all trade quality options enabled and even dithering has to be disabled...)
Radeon 3000 with 512MB ram on Windows 8.1...
I'll test again when I'll get back my gtx650ti (probably tomorrow).
annovif
7th April 2014, 18:06
Quote:
Originally Posted by annovif View Post
Hello everybody, can i know what kind of ATI i have to buy to set Needi 3 256 neurons with bluray?
For chroma upsampling or luma doubling or what? In any case, I'm not sure if any of today's GPUs can do that. NNEDI3 performance is more or less proportional to the neuron count. Which means that 256 neurons cost almost 16x as much performance as 16 neurons. Maybe for chroma upscaling 256 neurons could work with the fastest of today's GPUs, but I've not tested it, so I'm not sure. I don't think the benefit is high enough for chroma upscaling. I think 32 or 64 neurons is the max that is useful for chroma upscaling. But that's just my personal opinion, of course.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
I intended chroma upsampling bluray 23.976 over 1080p display . I hoped that 280x was good enough, but now i am not so sure. Thank you
mark0077
7th April 2014, 18:55
madshi, testing the new windowed mode on my machine with Nvidia GTX295 / Windows 8.1 and I notice a nice improvement in windowed mode. You might remember this bug http://bugs.madshi.net/view.php?id=153 where frames dropped on the first subtitle appearance in windowed mode. I got around it and saw 0 drops by using overlay mode but now I can also get 0 drops using the new windowed mode (although the queues do still take quite a drop :) ). So definitely an improvement over the old windowed mode, 0 drops.
One tiny issue I'm sure you'll solve before the final release. When testing with the new "windowed mode" -> "present several frames in advance" disabled. If I enable it mid playback and hit OK, the image freezes.
sandman7920
7th April 2014, 20:53
Is it possible for madVR to report Content Type to Display.
Movie, General, Game etc.
My tv support auto scene with option auto+24hz synchronization for cinema mode (madVR display mode switch 1080p24), but if video >24 in windowed mode tv stay in Desktop mode and in FSE switch to game mode.
P.S.
Sorry for my poor English
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.