View Full Version : madVR - high quality video renderer (GPU assisted)
huhn
3rd October 2015, 11:35
can you make a screen from the OSD?.
hybrid decoding is eating your GPU so there is most likely little to nothing left for madVR.
nevcairiel
3rd October 2015, 11:38
hybrid decoding is eating your GPU so there is most likely little to nothing left for madVR.
Braswell actually has a full hardware 8-bit decoder.
rbej
3rd October 2015, 11:54
can you make a screen from the OSD?.
hybrid decoding is eating your GPU so there is most likely little to nothing left for madVR.
Window DXVA Scaling On
http://images68.fotosik.pl/1226/e934603a003a835d.jpg
Full Screen DXVA Scaling Off
http://images70.fotosik.pl/1225/386a638f86a47801.jpg
huhn
3rd October 2015, 12:14
yeah it's 8 bit HEVC in this case.
the screens look borderline fine.
you can try an different presentation mode like overlay.
fullscreen takes a lot more processing power than windowed in your case and i don't think it is just dithering more pixel.
you can use GPU-z to have a look at the powerstates too.
madshi
3rd October 2015, 12:40
The problem started with v.0.88.6
http://forum.doom9.org/showthread.php?p=1722055#post1722055
Ups... Sorry. I checked again - the problem started with madVR-0.88.2
madVR-0.88.1 -- OK
madVR-0.88.2 -- "disable desktop composition" is not working
Ah, thanks! I think I know what this is:
The D3D11 presentation mode *requires* desktop composition to be enabled. So if you activate D3D11 presentation mode, madVR cannot disable desktop composition, anymore. Can you confirm that when disabling D3D11 presentation mode, disabling desktop composition works fine again?
I updated from .2 to madVR v0.89.5 today and since then I cannot move an already playing video frame (mpc-hc) to a second monitor. The picture just freezes but the sound continues to play.
Can you try producing a freeze report like this:
In the frozen situation press Ctrl+Alt+Shift+Pause/Break, then wait for 10 seconds, then there should be a freeze report text file appearing on your desktop. Upload that somewhere (don't attach it to this forum, takes too long to get approved).
There is definitely some weirdness with D3D11 in Windows 10.
I couldn't say whether it's the NVIDIA drivers, DWM changes, the introduction of virtual desktops/aero snap changes, or something else which is causing it.
I had to reduce the queue sizes to 6 to at least minimize how often things would occur.
I would end up with out-of-order frame presentation (looked like movement was jumping back and forth), screen tearing, or dropped frames.
And when playing multiple videos in succession in JRiver, it would "lose focus" after the first video and play in FSW rather than FSE - despite being in front of all the other applications.
None of this was consistently reproducible, which is why I haven't filed a bug report.
Due to those issues with madVR, and a lot of issues with other applications - including the OS itself - I've had to return to Windows 8.1.
10 really feels like a beta release right now, and I don't have the time to spend troubleshooting it at the moment.
There are definitely some things that it improves upon compared to 8.1, but it just doesn't feel finished.
That sounds pretty disappointing. FWIW, I think this is more likely to be a problem with the NVidia drivers than with Windows 10 itself, but I'm not 100% sure.
Is this a user configurable option? I can't find it in the zoom control settings tab or anywhere else, using Windows 7 x64 Pro.
It only exists in the "screen config" device settings page if you have a projector. The reason for that is that this option is mostly only useful for CIW (constant image width) front projection owners.
Guys, can I test chroma upscaling with image comparison like madshi did with luma in this post? http://forum.doom9.org/showthread.php?p=1730855&highlight=ground+truth#post1730855
It's possible, but difficult, due to 2 reasons:
1) You'd need to find an image, ideally some high quality RGB photo, where different chroma upscaling algorithms would show clear differences. In order to find such an image, you need to know what to look for. E.g. dark content with lots of black and red usually is a good idea. You should use an RGB photo which has full resolution chroma, maybe even scale it down a bit in RGB, so that the chroma channels really have full resolution and quality.
2) You need to convert the image to YCbCr 4:2:0, and you can't do that by simple downscaling chroma. You need to use the correct chroma offset, too! The chroma channel is not in center position compared to luma channel. It's slightly offset for all newer video codecs (MPEG2, h264, VC-1, h265 etc). Maybe LAV Video Decoder applies the proper offset when forcing it to output NV12? I'm not sure. @nevcairiel?
Zoom control doesn't work for me with native DXVA decoding. Is that intended or I should make a bug report ?
I wouldn't say "as intended". I'd like it to work for native DXVA decoding, too, but it's currently not possible to make that work because all the logic is running on the CPU. It's the same as with the forced film mode and with the deband "fade" detection. All that runs on the CPU and thus doesn't work when using native DXVA decoding. Maybe I can make it work at some point in the future. But it doesn't have high priority atm. IMHO for best quality you should use DXVA copyback or software decoding, anyway.
Subtitles position (edit: and size, they become smaller) is wrong when upscaling with latest madVR and MPC-HC(internal subtitle renderer).
Does this test build fix it?
http://madshi.net/madVR895kasper.rar
DontRenderAfterStop does eliminates blank frame during playrate change but still introduces some lag during playrate changes (both increase and decrease). The lag duration seems to depend on the bitrate of the file. The behaviour of the renderer seems to still be different from pre 88.16.
If it depends on the bitrate of the file then it points to the decoder being rather slow. Was 88.16 really that much faster in this situation? That would surprise me. In any case, I've implemented a special hack for you guys, I'm not going to spend hours on improving this purely cosmetical problem. Those hours would be much better invested in other things atm, to be frank.
I also notice the following - when playrate changes, the renderer temporarily displays a future frame (presumably the last frame in the buffer) before reverting to the earlier frame (with DontRenderAfterStop).
That sounds weird. Are you sure 88.16 didn't have this problem? I can't imagine why this should be a new problem.
I ran in to a problem with a 1920x1080 resolution tv serie, this doesnt honor the DXVA scaling, since there is no scaling needed, but chroma still needs to be scaled. So it 'falls back' to my choice in the chroma scaling option and therefor gets bad render times (im using Intel), instead of using DXVA for chroma scaling.
Yeah, you're right. The reason for that is that I'm not offering DXVA as a chroma upscaling choice at all right now (except in combination with DXVA scaling/decoding/deinterlacing), because I don't think DXVA is a good choice for that. I think DXVA chroma scaling is properly rather bad quality, anyway. So you could just as well simply set chroma upscaling to "bilinear" to get good performance with probably similar quality. And you still gain high quality color conversion by not using DXVA.
I found strange bug.
When i playing any 1080p 60fps movie in window - madVR show "image < DXVA". Playback is very smooth, without drops and skips. When i switch to full screen "image < DXVA" disappear and playback is poor with drops and skips. Why??. On EVR everything is ok.
I have NUC5PPYH (Braswell CPU), Windows 10 Home, last version MPC-HC, Lav filters and madVR.
madVR all scaling option set to DXVA2.
Can you upload a debug log for me? 20 seconds windowed playback, then 20 seconds fullscreen playback, then please close the media player directly, if possible without switching back to windowed again. Please zip the debug log and upload it somewhere (don't attach to this forum). Thanks.
The changer is not active, D3D9 is used (D3D11 not checket). With the previous version of madVR I never got problems, now with Windows 10 and the new build I got this issue.
Maybe important to say that the 23.976 fps (doubled with Avisynth in FFDShow to 47.952) remains stable and on the same memory bank even in fullscreen exclusive mode: it changes only with the 25fps (doubled to 50fps in the same way) to the 60Hz memory bank.
This is probably a GPU driver issue, maybe in combination with D3D9. You could try if D3D11 improves the situation. Or try enabling the madVR display mode switcher and entering those refresh rates you want madVR to use. Then madVR will try its best to force Direct3D to use the correct refresh rates.
And now I discovered another little issue: some subtitle from .MKV tv series are displayed in the center of the screen (in the middle of the image, to be clear), when with the 89.2 build were correctly displayed at the bottom of it. It doesen't happend with the DVD or BD subtitles (it may depend from the type of subtitle used in the .MKV? But I got no problem with them before this "subtitles manager version"...).
Does this test build fix it?
http://madshi.net/madVR895kasper.rar
Damn, the stutter-after-pause is still not fixed and occurs no matter what I try. Its quite annoying having to:
- close the video file
- experience screen-flash refresh rate change from 23Hz to 60Hz (Desktop is @ 60Hz and video files are @ 23Hz)
- open the file again
- experience another screen-flash refresh rate from 60Hz to 23Hz
- find the right spot to continue watching your video file (although I learned to remember the time at which I closed the video file to get back to watching quicker).
Is this bug on the list of "To-be-fixed soon" list?
Can you please make two screenshots of the debug OSD, one when playback is fine, and another when when that stuttering occurs? Does the OSD report frame drops/glitches when the stuttering occurs? Are the queues filled or empty? Which OS, which GPU?
Haven't got any logs but MadVR 0.89.5 is pretty unstable for me. About half of the time, MPC-HC doesn't exit properly when I close it, plus sometimes I'll open a video and the audio will play with no video. If I switch to EVR it plays fine. Hopefully I'm not the only one.
Does it crash or freeze? If it freezes, can you please create a freeze report and it upload it somewhere (don't attach to this forum)? Ctrl+Alt+Shift+Pause/Break.
Chroma upscaling is set to super-xbr and Image upscaling is set to Jinc3 AR; no profiles on either. The visual anomaly happens due to a large queue drop from the frame Cinemascope -> IMAX changes. Maybe the GPU can't adapt fast enough. The queue fills up about a second after the transition.
Would it be prudent to have a setting that alters the crop a handful of frames before having a relatively large increase in the resolution in the next scene? I increased the GPU/present queue sizes however it doesn't seem to make a difference in this case.
You didn't answer my question.
Is there anything in madvr about tearing that I'm possibly missing?
Just want to report spontaneous tearing issues as well. Win 10, GTX 960, newest NVidia driver. DX11 presentation (present every V-Sync ticked), only occurs in Fullscreen Windowed. Also newest MPC-HC nightly build. Its always fixed by simply changing the window size. It can occur less often in the middle of playback, more often when resuming playback.
This might somehow be related to having a multi-monitor setup, both by HDMI at 1080p. There doesn't seem to be anything I can do to 100% prevent tearing except for Fullscreen Exclusive. This isn't something I remember occurring before the time of, say the Win 10 RTM launch.
When you have tearing problems, it's likely not the fault of madVR.
Since Windows Vista, tearing shouldn't even be possible with GPU desktop composition, which can't be turned off anymore since Windows 8. So it's very likely a weird driver or configuration problem.
^
I upgraded to 89.5 and 0.66 LAV last night and was playing around with some options.
In animated content, I notice that if I use the SuperRes filter in Chroma Upscaling and use SuperRes in upscaling refinement; I get a bit of ringing and lines that are not smooth and are over sharpened. It doesn't get all that much better when I reduce the strength or increase the number of passes. Does this seem like normal behavior?
I don't know. Screenshots? If you get aliasing try increasing the SuperRes radius a bit.
I eventually settled on SuperRes in upscaling refinement and adaptive sharpen in the image enhancements section. Without adaptive sharpen, the lines seemed to fade in 480p > 1080p scaling.
Can you show screenshots that shows this "the lines seemed to fade" problem?
When playing some files the OSD shows this: [...]
When most of the time it shows:
Chroma>xxx
Image>xxx
Can some one explain why this happens?
This looks like a bug. When using super-xbr, luma and chroma should be treated the same way, so I have to check why the OSD reports them with different scaling paths.
Just a suggestion for Madshi.
Would it be possible to add OSD On/off to the pop-up menu from the system tray icon?
Yes, it would be possible. But I'm not sure how useful it would be. You're the first user ever to ask for this, so I have my doubts. Generally I would really like to keep the OSD tray icon menu as light weight as possible. Adding lots and lots of new menu items there will make it harder to use for everyone. So there should be a *VERY* good reason to add something there, and I'm not seeing it right now for OSD on/off.
mogli
3rd October 2015, 13:03
Thanks, the kasper test build fixed the small and wrongly positioned subtitles for me. :)
Ver Greeneyes
3rd October 2015, 13:48
Does this test build fix it?
http://madshi.net/madVR895kasper.rar
Thanks, the kasper test build fixed the small and wrongly positioned subtitles for me. :)
It doesn't fix it for me. Here's a small sample (http://www.mediafire.com/watch/5znhv06dve0s21u/sample.mkv) that still shows the problem. I'm using MPC-HC's internal renderer on the latest 64-bit Nightly build (1.7.9.165).
tFWo
3rd October 2015, 13:54
It doesn't fix it for me. Here's a small sample (http://www.mediafire.com/watch/5znhv06dve0s21u/sample.mkv) that still shows the problem. I'm using MPC-HC's internal renderer on the latest 64-bit Nightly build (1.7.9.165).
That's beacuse madshi only uploaded 32bit madvr.ax in the kasper build file. In the MPC-BE thread you can find his upload with both 32 and 64bit files.
madshi
3rd October 2015, 14:09
Here's a test build with both 32bit and 64bit files:
http://madshi.net/madVR895c.rar
Ver Greeneyes
3rd October 2015, 14:20
That's beacuse madshi only uploaded 32bit madvr.ax in the kasper build file. In the MPC-BE thread you can find his upload with both 32 and 64bit files.Oh, that's embarrassing - I completely forgot about the 32-bit/64-bit split.
Here's a test build with both 32bit and 64bit files:
http://madshi.net/madVR895c.rar
Yep, that fixes it. Thanks madshi!
rbej
3rd October 2015, 15:17
How enable debug mode in madVR?.
When i run "activate debug mode" - "file madVR.ax not found'. Very strange. madVR.ax is here.....
Siso
3rd October 2015, 16:07
OK, a small question regarding the internal subtitles in mpc-hc,mpc-be and potplayer - when they are enabled madvr's max stats jump up to 50% example: from 15 ms to 25 ms -30 ms. This happen when subtitles are shown on screen. CPU xeon 5650 @ 3,6 ghz 6 cores, video card GTX 550 TI 314.22 drivers, tried new drivers same result.
kasper93
3rd October 2015, 16:10
@Siso: Try latest MPC-HC's beta version https://nightly.mpc-hc.org/ It shouldn't affect madVR's render times anymore.
Siso
3rd October 2015, 16:49
@Siso: Try latest MPC-HC's beta version https://nightly.mpc-hc.org/ It shouldn't affect madVR's render times anymore.
I tried it but not much of a difference...
rbej
3rd October 2015, 17:17
Can you upload a debug log for me? 20 seconds windowed playback, then 20 seconds fullscreen playback, then please close the media player directly, if possible without switching back to windowed again. Please zip the debug log and upload it somewhere (don't attach to this forum). Thanks.
Full screen DXVA Scaling Off
http://www18.zippyshare.com/v/hDhY6T1f/file.html
Windowed playback (DXVA Scaling On) with debug mode is very poor. Without debug mode windowed playback is very smooth.
zveroboy
3rd October 2015, 17:42
Ah, thanks! I think I know what this is:
The D3D11 presentation mode *requires* desktop composition to be enabled. So if you activate D3D11 presentation mode, madVR cannot disable desktop composition, anymore.
http://forum.doom9.org/showthread.php?p=1722068#post1722068
Can you confirm that when disabling D3D11 presentation mode, disabling desktop composition works fine again?
No. The check box "use Direct3D 11 for presentation" is off, but disabling desktop composition dont work.
0.89.5 - the same behavior.
madshi
3rd October 2015, 18:12
Here is a new test build for those that had freezes with v0.89.5 when closing the media player, or when switching video files, or moving the media player to a different monitor:
http://madshi.net/madVR895d.rar
Does this build fix those freezes/stability issues?
How enable debug mode in madVR?.
When i run "activate debug mode" - "file madVR.ax not found'. Very strange. madVR.ax is here.....
If the batch file doesn't work, open it with an editor to see what it does, and do it manually instead. The batch file simply renames some files, it's very simple.
Full screen DXVA Scaling Off
http://www18.zippyshare.com/v/hDhY6T1f/file.html
Windowed playback (DXVA Scaling On) with debug mode is very poor. Without debug mode windowed playback is very smooth.
That's strange, there should be no big difference between debug and release builds.
Anyway, the log only contains fullscreen playback. I asked for 20 seconds windowed and fullscreen each, so I can compare.
No. The check box "use Direct3D 11 for presentation" is off, but disabling desktop composition dont work.
0.89.5 - the same behavior.
Ok, try this build from the top of this comment. Does that help?
zveroboy
3rd October 2015, 18:55
Ok, try this build from the top of this comment. Does that help?
Yes.
madVR895d is OK.
Many thanks!
rbej
3rd October 2015, 18:58
Anyway, the log only contains fullscreen playback. I asked for 20 seconds windowed and fullscreen each, so I can compare.
Windowed mode
http://www69.zippyshare.com/v/8GnhYMKu/file.html
Full screen mode
http://www18.zippyshare.com/v/hDhY6T1f/file.html
madshi
3rd October 2015, 19:29
madVR895d is OK.
Good to hear!
Windowed mode
http://www69.zippyshare.com/v/8GnhYMKu/file.html
Full screen mode
http://www18.zippyshare.com/v/hDhY6T1f/file.html
Ok, thanks. Which trade quality for performance options do you have set?
The new windowed mode doesn't work well for you?
madshi
3rd October 2015, 19:41
Yes, I'll be around next weekend for testing. No problem.
Ok, here's a new test build. Will need a new log, thanks.
http://madshi.net/madVR895f.rar
Doubling with e.g. super-xbr works without that delay for you now? It's only NNEDI3 making trouble, correct?
rbej
3rd October 2015, 19:41
Good to hear!
Ok, thanks. Which trade quality for performance options do you have set?
The new windowed mode doesn't work well for you?
Trade quality - default. i dont change anything.
New windowed mode working well.
madshi
3rd October 2015, 19:52
Trade quality - default. i dont change anything.
New windowed mode working well.
The new windowed mode works well in fullscreen, too? Is there a reason why you were using the old mode?
rbej
3rd October 2015, 19:59
The new windowed mode works well in fullscreen, too? Is there a reason why you were using the old mode?
New windowed mode not working well in full screen. Playback is still poor.
No reason. I tested new and old windowed mode.
Damien147
3rd October 2015, 20:31
Subtitles are in the center when being fullscreen,anyone else?
kasper93
3rd October 2015, 20:42
@Damien147: You can always read few posts before and you will know what to do.
Damien147
3rd October 2015, 20:49
Ok,thanks.
Stan
3rd October 2015, 21:26
Here is a new test build for those that had freezes with v0.89.5 when closing the media player, or when switching video files, or moving the media player to a different monitor:
http://madshi.net/madVR895d.rar
Does this build fix those freezes/stability issues?
Fixed for me, thank you very much!
XRyche
3rd October 2015, 21:42
Ok, here's a new test build. Will need a new log, thanks.
http://madshi.net/madVR895f.rar
Doubling with e.g. super-xbr works without that delay for you now? It's only NNEDI3 making trouble, correct?
Yes only NNEDI3 image doubling is giving me issue and NNEDI3 chroma upsampling as well. Although, as I stated previously, NNEDI3 chroma upsampling shows the correct colours when used in conjunction with Super-Res.
On an unrelated note, madVR895c is positioning the internal subtitle renderers subtitle placement correctly for me now as well.
XRyche
3rd October 2015, 21:54
Ok, here's a new test build. Will need a new log, thanks.
http://madshi.net/madVR895f.rar
Here's the log: https://www.mediafire.com/?auan6vyygdwfrra .
madshi
3rd October 2015, 22:30
Fixed for me, thank you very much!
Good to hear!
Here's the log: https://www.mediafire.com/?auan6vyygdwfrra .
Thanks. Ok, it's official now: For some reason, creating the OpenCL command queue takes about 10 seconds on your PC. I don't know why, but that's how it is. This looks like a problem with your OpenCL installation. There's nothing I can do about it. It seems you can either try repairing your OpenCL installation somehow (I don't know how). Or alternatively you'll have to give up on NNEDI3 for now. I might offer a NNEDI3 option without OpenCL in the future.
New windowed mode not working well in full screen. Playback is still poor.
Ok, can you please make a debug log with this test build?
http://madshi.net/madVR895g.rar
chros
3rd October 2015, 22:39
There's no difference for me. On the right side, there is new windowed path and on the left side, it's old FSE mode:
http://abload.de/thumb/windowednewbrj8n.png (http://abload.de/image.php?img=windowednewbrj8n.png)
It's the same with old windowed path.
My test case was 1080p60 -> WQHD with Jinc3 + SuperRes 2 passes + Adaptive Sharpen.
Hhmmm... That's interesting. Maybe your card is so powerful, or it depends on lot's of things. Are you sure that you used D3D9 exlusive (old path)? :)
Here're my results (see my signature for details):
0. I'd been done testing on the 1080p TV, using nvidia with DXVA-copyback in LAV video, dithering on, all trading performance are switched off, no smooth motion, no other processing. I tried to select the lowest gpu and memory freq where the queues are still full. (max values: gpu 745MHz, ram: 2000MHz)
1. I managed to use Overlay mode (finally): but only with iGPU (intel) and only when I was tested on TV (my AV receiver is recognized otherwise as a cloned display device, that's why I got blank picture when I tried it on my laptop screen :) )
2. 720p (1280x720) 25fps video, chroma Jinc+AR, luma Jinc+AR:
- D3D9 FSE new path: gpu 690MHz, mem 2000MHz (gpu usage: 90-92%)
- D3D9 FSE old path: gpu 450MHz, mem 800MHz !!! (gpu usage: 97-99%, but playback is without a problem)
3. 1080p (1920x1080) 23.976fps video, chroma super-xbr+AR:
- D3D9 FSE new path: gpu 490MHz, mem 900MHz (gpu usage: 90-92%)
- D3D9 FSE old path: gpu 405MHz, mem 405MHz !!! (gpu usage: 80-82%) This result is actually insane!!! -> we use the lowest settings in P8 state :) (P12->P8->P5->P0)
4. The above values are valid. Both GPU-Z and nvidiainspector shows them, plus the thermal monitor app for CPU and GPU is also right on both cases.
5. I noticed 1 more thing in my system: the new path is way more ram consuming then the old one. In both tests I had to raise the ram clock not just the gpu clock.
6. All the rest of the modes (FS Windowed new/old path, FS Overlay, FS D3D11) were about the same speed like FSE new path was (only D3D9 old path is different completely).
7. The results were similar when I tried it out on the intel iGPU (with different scaling algos, since it's not so powerful than the nvidia), D3D9 FSE old path was way faster than the rest.
8. conclusion: if you do care about performance AND you don't/can't use NNEDI3 AND you don't use 10bit output, then give the D3D9 old path a chance! :) You can test how it behaves within 5 minutes. :)
Madshi, what could cause such a big performance difference?
It's a technical limitation and there's not much I can do about it, without totally rewriting the "old exclusive mode".
You don't need t worry about it, since it's the fastest mode for me, thanks!
It's possible, but difficult, due to 2 reasons:
1) You'd need to find an image, ideally some high quality RGB photo, where different chroma upscaling algorithms would show clear differences. In order to find such an image, you need to know what to look for. E.g. dark content with lots of black and red usually is a good idea. You should use an RGB photo which has full resolution chroma, maybe even scale it down a bit in RGB, so that the chroma channels really have full resolution and quality.
2) You need to convert the image to YCbCr 4:2:0, and you can't do that by simple downscaling chroma. You need to use the correct chroma offset, too! The chroma channel is not in center position compared to luma channel. It's slightly offset for all newer video codecs (MPEG2, h264, VC-1, h265 etc). Maybe LAV Video Decoder applies the proper offset when forcing it to output NV12? I'm not sure. @nevcairiel?
Sorry, but this was like Chinese language to me :)
I made a chroma comparison test with the video "mp4.v2c\Misc Patterns\A - Additional\3-Color Steps.mp4" from AVS.HD.709.v2d.Calibration (http://www.avsforum.com/forum/139-display-calibration/948496-avs-hd-709-blu-ray-mp4-calibration.html) of AVSforum, in windowed fullscreen mode, the zipped pngs are here: http://www10.zippyshare.com/v/bDzpW31T/file.html
(NN: nearest neighbour, SX: super-xbr+AR, Jinc: Jinc+AR, SR: superres strenght1, SR2: superres strenght2)
What I can see on the images that Superres adds unwanted bright edges that can be visible at the red rectangles on the right side of the pictures.
Apart from this, I can't tell the difference between the tested 3 algos (NN, Jinc+AR, SX+AR), maybe the test video wasn't aproppriate for this. :)
rbej
3rd October 2015, 23:21
Ok, can you please make a debug log with this test build?
http://madshi.net/madVR895g.rar
Full screen and windowed.
http://www71.zippyshare.com/v/w9ImBFgK/file.html
Asmodian
3rd October 2015, 23:22
What I can see on the images that Superres adds unwanted bright edges that can be visible at the red rectangles on the right side of the pictures.
Apart from this, I can't tell the difference between the tested 3 algos (NN, Jinc+AR, SX+AR), maybe the test video wasn't aproppriate for this. :)
In this situation I recommend you use Catmul-Rom or madVR's default of Bicubic 75, they are very close anyway.
These are quite fast/cheap but offer much improved quality compared to NN in past tests. Since you cannot see the difference even when using NN the more expensive algorithms are a waste of power but bicubic is low enough power the small improvements in scenes you haven't tested might be worth it.
Note: that 3-Color-Steps is probably one of the worst images to test chroma scaling options with. You want fine color details.
XRyche
3rd October 2015, 23:23
Thanks. Ok, it's official now: For some reason, creating the OpenCL command queue takes about 10 seconds on your PC. I don't know why, but that's how it is. This looks like a problem with your OpenCL installation. There's nothing I can do about it. It seems you can either try repairing your OpenCL installation somehow (I don't know how). Or alternatively you'll have to give up on NNEDI3 for now. I might offer a NNEDI3 option without OpenCL in the future.
Well that's disappointing to hear. When I upgraded to Windows 10 it must have messed up my OpenCL because it worked perfectly fine on Windows 8.1. Thanks for trying to fix my issue so diligently madshi.
I have an idea, might not be a good idea but it's an idea nonetheless.
Is anyone with NNEDI3 working on Windows 10 willing to give me a copy of their OpenCL.dll from their SysWOW64 folder?
aufkrawall
3rd October 2015, 23:26
Has Display Driver Uninstaller been suggested before?
http://www.wagnardmobile.com/forums/viewforum.php?f=5&sid=4b86b899e219d0f9164a0da209cb9bc2
XRyche
3rd October 2015, 23:34
Has Display Driver Uninstaller been suggested before?
http://www.wagnardmobile.com/forums/viewforum.php?f=5&sid=4b86b899e219d0f9164a0da209cb9bc2
I use that exact app every time I change display drivers. Thanks for the suggestion though.
XRyche
3rd October 2015, 23:46
Unfortunately, the OpenCL.dll from someone's working NNEDI3 on Windows 10 didn't change anything. Anyone have any suggestions, besides rolling back to Windows 8.1?
nevcairiel
3rd October 2015, 23:54
Unfortunately, the OpenCL.dll from someone's working NNEDI3 on Windows 10 didn't change anything. Anyone have any suggestions, besides rolling back to Windows 8.1?
Clean install, not upgrade. :)
XRyche
4th October 2015, 00:46
Clean install, not upgrade. :)
Well that's a pain. Oh well, I'd rather have NNEDI3 working properly so I guess I'll do just that. Thanks for the suggestion nevcairiel.
aufkrawall
4th October 2015, 01:40
Hhmmm... That's interesting. Maybe your card is so powerful, or it depends on lot's of things. Are you sure that you used D3D9 exlusive (old path)? :)
Yep. Probably it's really the slow hardware or driver for old hardware behaves differently.
6ari8
4th October 2015, 06:31
The first chroma entry is for chroma upsampling from 4:2:0 to 4:4:4. The second chroma entry is for chroma upscaling for matching the chroma to the luma upscaled resolution. I believe that's correct but if not fell free to correct me anyone.
If you're talking about this (http://s1.postimg.org/tsoq7hwen/Untitled.png)one then the resolution still doesn't match at the end since luma is downscaled whereas chroma is not.
That's because madVR isn't displaying the quad superxbr scaling that happens automatically alongside the luma scaling.
It has to match before it gets displayed.
I think it shows it in the double chroma line version but what is confusing is that the components' resolution doesn't match if we go by the OSD (everything matches until Luma is downscaled).
If it says "Image" in the OSD, it refers to scaling both Luma and Chroma at the same time (otherwise it would say Luma)
So what it really does is only 2 steps
1) Double Chroma to 712x480, now matches Luma
2) Double the entire image twice (both Luma and Chroma) to 2848x1920, then downscale both components to 1920x1080
That's how I understood it when the OSD was like this (before 89.05):
http://s16.postimg.org/ic7mqcqrl/Untitled.jpg (http://postimg.org/image/ic7mqcqrl/)
But this one (89.05) doesn't make sense to me
http://s1.postimg.org/6egqvkeh7/Untitled.jpg (http://postimg.org/image/6egqvkeh7/)
because it doesn't match the luma and chroma resolutions.
This looks like a bug. When using super-xbr, luma and chroma should be treated the same way, so I have to check why the OSD reports them with different scaling paths.
It's not limited to suber-xbr though. It shows the same info when choosing NEDI as well.
But even though the scaling paths are treated differently, doesn't it show that the luma and chroma resolutions are not matched?
Video resolution: 712x480, 4:2:0
chroma > super-xbr | 356x240 > 712x480
luma > super-xbr > super-xbr < Catmull-Rom AR | 712x480 > 1424x960 > 2848x1920 < 1920x1080
chroma > super-xbr > super-xbr | 712x480 > 1424x960 > 2848x1920
madshi
4th October 2015, 07:55
Full screen and windowed.
http://www71.zippyshare.com/v/w9ImBFgK/file.html
Does this build work better?
http://madshi.net/madVR895j.rar
It's not limited to suber-xbr though. It shows the same info when choosing NEDI as well.
As I already said, it looks like a bug. Try any of the recent test builds, it should already be fixed in there.
rbej
4th October 2015, 08:45
Does this build work better?
http://madshi.net/madVR895j.rar
Now works perfect on full screen. Thanks!!
madshi
4th October 2015, 10:25
madVR v0.89.6 released
http://madshi.net/madVR.zip
* updated AdaptiveSharpen to latest version
* added support for ISubRenderCallback3 interface
* optimized DXVA fullscreen playback performance
* fixed: freezes when closing media player, or switching to different monitor
* fixed: another DXVA related crash
* fixed: subtitle positioning was sometimes incorrect with MPC-HC/MPC-BE
* fixed: disabling desktop composition was broken
* fixed: slow switching between two h264 TV stations with identical resolution
* fixed: OSD scaling information was sometimes incorrect
* fixed: "setZoomOffsetX = -1" resulted in madVR totally stopping to work
rafi.hamid
4th October 2015, 11:18
for gtx 980ti and i5 4690 what is the best settings?
thanks
Sent from my iPad using Tapatalk
James Freeman
4th October 2015, 11:37
The best of the best or only the best?
madVR is the best of the best of the best, so it has a point where you get diminished returns and a huge electrical bill with the best of the best of the best settings.
:D
Start here: http://forum.doom9.org/showthread.php?t=171787
panetesan2k6
4th October 2015, 11:39
The best of the best or only the best?
Best answer I can give you is to read this and form your own opinion:
http://forum.doom9.org/showthread.php?t=171787
rafi.hamid
4th October 2015, 11:57
thanks for help
that link is to complicated for me because I am a beginner and also not good enough in English language.
what you think about below link is it good for me?
https://imouto.my/madvr/
Sent from my iPad using Tapatalk
James Freeman
4th October 2015, 12:00
what you think about below link is it good for me?
https://imouto.my/madvr/
Yes, good enough.
It's important to emphasize that there is a point where madVR will use a LOT of resources without visible difference.
Especially "Image Doubling".
Use Nvidia Inspector to look at how much % of the GPU and Memory is used.
Ctrl+J in the player will open madVR OSD that will show stats, look for dropped frames.
Go slowly and observe.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.