View Full Version : madVR - high quality video renderer (GPU assisted)
ShadyCrab
17th September 2015, 12:29
HBM2, likely hardware scheduling for Async Compute (or fine-grained software pre-emption, eitherway), big improvements in FP16 performance, likely better Direct3D 12 support (more full-heap support for resources and likely better Conservative Rasterization support), generational improvements, possible HDMI 2.0a support, likely DisplayPort 1.2a support (G-SYNC 2.0 likely, current G-SYNC may not be sustainable), better VR support, possible VP9 hardware decoding (and full HEVC decoding across the entire lineup) and many more possibilities (wish there were more definitive statements on what to expect with Pascal) should make the next-generation Pascal cards a huge step-up, and a solid improvement platform wise. Also, 14/16nm should also provide big generational improvements. Absolutely worth waiting for. Buying a 950 might help hold-over until then however. Really cannot wait :)
Great work on madVR 0.89 madishi. New option to prevent upscaling when the difference is only 5-6 pixels helped reduce power-consumption for some videos big-time, thankyou. Any news on when the Chroma SuperRes will be updated to the newer code/algorithm?
Serhiyko
18th September 2015, 14:30
Which subtitle renderer are you using?
The built-in subtitle renderer
Also, starting with madVR v0.88.9, when I Save Image in windowed mode, if the size of the window is smaller than the original size of the video, the size of snapshots equals the size of the resized video, not the original size. It's not the case in the fullscreen mode or any previous version of madVR
BluesFanUK
18th September 2015, 18:37
Whoa.
I reinstalled Potplayer today and MadVR and my videos are appearing massively zoomed in, crashing my PC.
Is this some sort of setting in MadVR I need to disable? Both options on Zoom control are unticked and all three boxes for upscaling refinment are unticked.
vivan
18th September 2015, 18:56
It's a known bugThat's my fault, sorry about that, should hopefully be fixed in the next build.
CiNcH
18th September 2015, 20:16
Problem:
Switching between 1080i and 576i channels often results in madVR totally getting stuck (picture freeze). Log attached... it happened in last switch from 1080i to 576i.
madVR - log (https://www.dropbox.com/s/e1stus5kkl8vvoq/madVR%20-%20log.rar?dl=1)
Magik Mark
18th September 2015, 23:11
Hi Madshi! We miss you so much. We can't live without you
ryrynz
19th September 2015, 01:15
Hi Madshi! We miss you so much. We can't live without you
First good LOL of the day. Tnx.
lanzorg
19th September 2015, 03:26
@madshi
- Could you upgrade adaptive sharpen and super-res?
- Is it possible to make device modes like in kodi, just an on/off button?
Dlget
19th September 2015, 19:01
2nd weekend
Waiting for nnedi3 workout for win10 with nvidia cards
Madshi may be working right now
baii
19th September 2015, 19:56
Win 10 have nothing to do with nnedi3.
Sent from my SM-T700 using Tapatalk
Siso
19th September 2015, 21:16
Whoa.
I reinstalled Potplayer today and MadVR and my videos are appearing massively zoomed in, crashing my PC.
Is this some sort of setting in MadVR I need to disable? Both options on Zoom control are unticked and all three boxes for upscaling refinment are unticked.
+1 for potplayer crash
baii
20th September 2015, 00:17
You can go back to .891, or earlier build if you don't need the zoom control features.
Sent from my 306SH
Siso
20th September 2015, 08:14
You can go back to .891, or earlier build if you don't need the zoom control features.
Sent from my 306SH
I'm with 21:9 display and I need them :)
bcec
20th September 2015, 16:26
Win 10 have nothing to do with nnedi3.
perhaps you missed where he said "with nvidia"
or perhaps you are just trolling
foozoor
20th September 2015, 16:34
@madshi
- Could you upgrade adaptive sharpen and super-res?
- Is it possible to make device modes like in kodi, just an on/off button?
Why not using mpdn instead? Did you try it?
The player has all you asked a while ago already.
I saw some madshi's posts on the svp project forum.
He talked about vapoursynth support, but said that he was quite busy.
Madshi, do you work on it or something else?
Please keep us informed a little bit more because anxiety is growing for some people. ;)
Sunset1982
20th September 2015, 21:10
Thank you Madshi for your had work and the new version 0.89.3! :thanks:
madshi
20th September 2015, 21:18
I'd like to see this return also - it was handy for determining what resolution the current video was playing at (not the actual video clip resolution, but the actual resolution currently being used, taking into account the window size - I'd have to use an on-screen ruler tool to get that window size now that it has been removed from madVR).
i would like to see both like how it is in 88.21. so i can see the orig movie resolution and the final movie target rectangle.
I'd like to see the information what exact size the portrayed video by the player has.
This is very useful when resizing to a certain resolution (e.g. when you want to resize pixel exact to a size that isn't offered by the player as a template like "50%" or you want to make sure the player really resizes as it's told).
Otherwiese I might be really handicapped when doing image quality comparisons in the future. :(
Guys, I see this is in demand, but the new "zoom control" settings really made this complicated. E.g. if a black bar is detected and you activate "crop black bars" then madVR actually cuts the original image size down to remove the black bars. But if you don't activate "crop black bars", then the bars stay and madVR adjusts the target rect so that it goes outside the player window, so that any letter boxing is exactly zoomed away. And all the various "zoom control" settings have a lot of influence on the exact target rect.
Basically in v0.89.x the media player is not in full control over the exact target rect, anymore. Instead madVR tries to understand what the media player wants and then calculates a new target rect which is then used for actual rendering (and which the media player doesn't know anything about). madVR tries to follow the media player wishes, but taking the detected black bars and the user wishes (zoom control) into account, too.
So just writing one target rect into the OSD won't tell the whole picture. I would have to at least write the modified source rect (modified by black bar detection) and the final target rect (calculated by madVR) into the OSD, and that could be quite confusing for many users. Is that really so very useful?
For image quality comparisons you should be using 100% view, anyway, shouldn't you? If you do that, and if you disable zoom control, then the target rect should be exactly 100% of the native video size (after aspect ratio correction).
When I activate debug mode it says "cannot find madvr.ax". I have MPC-HC running and playing a video with the OSD for madVR displayed so obviously it's using madVR.ax. So I don't seem to be able to upload a debug log :confused: .
You need to double click that batch file when the media player is closed. Then it should work.
Here is the log from madvr debug, not sure what to look for my self and the log was huge so I only include the first 20K lines or so.
From what I can see it seems that you don't have display mode changing activated in madVR? From what I can see, Direct3D wants to use 1920x1080 with 29.970Hz. And since madVR's display mode changer doesn't seem to be active, madVR is just fine with that.
I've tried using touch window from outside and stretch to window but both have no effect, the osd shows touch window from inside and the black bars remain visible. I'm using the latest 64bit nightly build, zooming the bars away works but zooms in and cuts off the subtitles which of course you don't want.
Not an ideal solution but works as expected, It's not a big deal but would be handy if you could add the ability to simply crop the black bars away completely when you have time.
What happens if you active the options "if there are big black bars ... zoom the bars away completely" and "zoom small black bars away" in the madVR zoom control settings? Does that do what you want?
I use JRiver Media Center 20 with Red October HQ mode, so madVR.
I have a weird issue with display mode changer in that it just kills the video driver (NVIDIA GTX 750 Ti) which requires a reboot to fix.
That sounds very bad. Does it happen with both "use Direct3D 11 for presentation" enabled and disabled in the madVR "rendering\general settings"? This is very likely a bug in the GPU drivers. Have you tried installing a different driver version?
I updated Seven to Windows 10 (not a clean installation but using Windows mode) and I got a strange issue using MadVR with MPC-HC and the same settings.
When the player switches to exclusive mode seems like that the resolution changes to 60 Hz form 25 because the CRT projector goes to the appropriated memory bank; if I leave the exclusive mode visualizing the menu (or the seek bar, ecc.) the CRT goes back to the 50 Hz memory back.
Do you have the madVR display mode changer active? If so, which settings are you using? If not, then Direct3D itself decides which refresh rate to use in fullscreen exclusive mode.
The feature "restore original display mode when media player leaves fullscreen" is not working for me with MPC-HC + LAV codecs (x64).
Can anybody reproduce that problem?
A very small bug in madvr:
In the settings dialog, under processing, image enhancements, LumaSharpen, the value for clamp is 0.035 after a fresh install. If you push the restore defaults button on the image enhancements page, the value changes to 0.010. So either the restore defaults button should make clamp 0.035, or the fresh settings should have the value as 0.010.
Will fix that for the next build (not v0.89.3).
BTW, is it possible to include duration to profile rules?
What duration do you mean? Do you mean the movie runtime? What would you need that for in profiles?
Also I think banding is unbalanced, low is almost no-op.
In a 10/10 scale is as if low was 2, mid was 4 or 5 and high 10, Whereas something more balanced could be 3, 6, 10.
I suggest to raise "low" one notch, and "mid" one or two notches above.
A couple months (years?) ago when I was working on debanding, many madVR users did a lot of testing and giving feedback, and the settings are based on that. "low" is intentionally very light weight, so that you can enable it without worrying much about losing image detail, while still getting "some" benefit. "high" is set to be as strong as possible, without going totally crazy. "mid" it still somewhat careful, but noticeably stronger than "low". IMHO both "low" and "mid" are settings that I could imagine turning on and leaving on at all times. Which I wouldn't do with "high". If I raise "mid", it would get so strong that I couldn't recommend keeping it on, anymore.
Considering that A LOT of feedback from many madVR users went into defining the exact low/mid/high settings, and that I like the way they are currently set up, I don't think it would be a good idea to change them now.
Also thinking out loud here, but could it be possible to add some "software" based anti-strobing effect, I mean I see how I could use it for "cinema mode". I know some Smart TV's have the option but it is actually hidden, not very self explanatory nor very accessible for the daily use, so having it set in madVR software with rules could be a nice addition. This would involve inserting a black frame every other source frame, then the TV changing to this framerate mode (47.95FPS for films). Have I said something stupid or could this actually work?
I've had this in my mind for a long time. The problem with this is that doing that at 48Hz is far too slow, it would flicker like crazy. With 120Hz it starts becoming possible, but how many TVs are accepting 120Hz via HDMI? Some monitors do, but madVR is mostly meant for TVs and projectors. As long as those don't support high refresh rate input, I don't think black/dark frame insertion by madVR makes a lot of sense.
edit: btw I get constant frame drops when changing from display to another, as if madVR didn't unhooked the video drivers at all. That is watch a movie on TV, close the player, switch to monitor (other resolution, color profile, etc), play a video, major frame drops... it eventually fixes after playing some videos or so but it's annoying.
This happens even if you stop the player and restart it?? In that case there really isn't anything I can do about it. Whatever madVR does should be totally reset by the OS when the media player closes. Must be a driver or OS issue.
Can anyone please test for video freezing after pause and unpause several times.
I will try to find in what version this appeared.
EDIT:
Okay, found it.
89.0 introduced it, 88.21 is OK.
Try pause and unpause (space bar) repeatedly and look at the Play/Pause OSD.
The OSD should stop responding, and when you pause the OSD will stay/show "Play" even though the video is paused.
Now unpause and the video will freeze.
Wait 10 seconds and pause and unpause the video, you should see the video speed up to its current position.
It happens only in Overlay Mode.
madVR sometimes shows something in RED font and disappears very quickly, I can't read it.
And you can reproduce this easily with v0.89.x but not at all with v0.88.21? Are you absolutely sure about that? In that case I'd like to see a debug log with v0.89.3 where this problem occurs. Once the video freezes, please let it stay frozen for 20 seconds, then close the media player and upload the debug log (zipped). Thanks!
Any news on when the Chroma SuperRes will be updated to the newer code/algorithm?
Probably not far away now. Still some other things to do first, though.
The built-in subtitle renderer
Ah yes. Newer madVR builds don't fully rerender the paused video frame all the time, to save resources. If you use the built-in subtitle renderer then madVR does not know that you changed the subtitle track, so I don't know that I need to rerender the video frame. I'm not sure if I can solve this without pushing GPU power through the roof again in paused mode. And frankly, I don't think this is important enough to make compromises with high GPU power in paused mode.
Also, starting with madVR v0.88.9, when I Save Image in windowed mode, if the size of the window is smaller than the original size of the video, the size of snapshots equals the size of the resized video, not the original size. It's not the case in the fullscreen mode or any previous version of madVR
This might have to do with which decoding and scaling options you're using. Are you using DXVA decoding and/or DXVA scaling?
- Could you upgrade adaptive sharpen and super-res?
Adaptive Sharpen next week. Not sure if there is a new (luma) SuperRes version to update to. But I did plan to work a bit on SuperRes. Might take a bit, though.
Is it possible to make device modes like in kodi, just an on/off button?
Not sure what you mean?
Problem:
Switching between 1080i and 576i channels often results in madVR totally getting stuck (picture freeze). Log attached... it happened in last switch from 1080i to 576i.
madVR - log (https://www.dropbox.com/s/e1stus5kkl8vvoq/madVR%20-%20log.rar?dl=1)
Hmmm... I've looked into your log, but I'm trouble finding the right place. I've checked the last switch from 1080i to 576i in the log. After the switch it takes about 1 second for the decoder to start sending new frames, and madVR displays them then just fine. At least the log seems to say so. After that there's another switch back to 1080i, and rendering still seems to work fine.
Can you retry with v0.89.3? If the problem still occurs with that build, maybe you could create a new log with v0.89.3 for me? When madVR gets stuck, let it stay in that state for 20 seconds. Then close the media player immediately without switching to another station. Maybe then I can find the right place to look at in the log better. Of course it's also possible that madVR thinks it's rendering successfully, but for some reason the rendered images aren't making it through to the display...
madshi
20th September 2015, 21:19
Thank you Madshi for your had work and the new version 0.89.3! :thanks:
Hey, you're quick - I haven't even announced it yet!!
huhn
20th September 2015, 21:30
I've had this in my mind for a long time. The problem with this is that doing that at 48Hz is far too slow, it would flicker like crazy. With 120Hz it starts becoming possible, but how many TVs are accepting 120Hz via HDMI? Some monitors do, but madVR is mostly meant for TVs and projectors. As long as those don't support high refresh rate input, I don't think black/dark frame insertion by madVR makes a lot of sense.
i already used that on a 120 Hz screen this is not usable. the brightness drops way to low. so for proper viewing there has to be a way to counter this. i wouldn't be shocked if the whole gamma curve is not correct anymore.
madshi
20th September 2015, 21:30
madVR v0.89.3 released
http://madshi.net/madVR.zip
* NNEDI3/OpenCL now uses D3D11 interop instead of D3D9 interop
* implemented most of the various missing black bar features
* added support for device profiling
* added vertical scrollbar to "profile auto select rules" edit field
* added "smoothmotion" bool value for profile rules
* fixed: sometimes video was zoomed in way too much without any reason
* fixed: black bar detection sometimes had false positives
* fixed: black bar detection sometimes unnecessarily dropped correct detection
* fixed: DXVA processing sometimes broke when stopping & starting the graph
* fixed: sub options were active even if black bar detection was off
Important things in this release:
1) NNEDI3 now uses a different interop interface, which seems to perform slightly faster for NVidia and quite noticeably faster for AMD. Also it should work with newer NVidia drivers on Windows 10. I haven't tested yet whether the interop problem is gone for AMD, but there's a good chance that it is.
On the negative side, v0.89.3 requires Windows 7 or newer for NNEDI3, so unfortunately Windows XP and Vista users can no longer use NNEDI3. I'm sorry about that, but making the new code XP/Vista capable would have been too much work and not worth the effort, IMHO. Go upgrade to Windows 7 (or newer). It's about time.
Since the new interop is brand new, don't be surprised if there are some new bugs. It does work well on my PC, though.
2) madVR can now "notify the media player about cropped black bars". Basically that means that in non-fullscreen windowed playback mode the media player can now automatically adjust the window size in such a way that no black bars are part of the window at all, anymore. Some media players do this better than others, though. Here's a list of media players with recommend settings to make use of this new feature:
MPC-HC & MPC-BE:
Player -> Limit window proportions on resize
Playback -> Auto-zoom: "100%" or "Autofit"
ZoomPlayer:
Interface -> Position & Size -> Auto-Size User Interface to maintain Video Aspect Ratio (when resizing)
Interface -> Position & Size -> Auto-Size User Interface to fit Source Video Resolution (on load)
PotPlayer:
Playback -> Aspect Ratio -> Fit Window to Image Size
These 4 media players do (more or less) already work well with the new madVR feature. MPC-HC & MPC-BE do this best, although both still have room to improve here, as well. ZoomPlayer and PotPlayer don't auto resize their window if madVR tells them to, but at least they adjust the window size to the video when you resize the window. So it's partially working.
Most other media players don't support the new feature. Which means the new feature will simply have no effect on them at all.
3) Most of the other zoom control features are fully implemented now. Give them a try!
4) For those who need it, you can now create profiles in the "device" section.
retrue
20th September 2015, 21:34
Madshi, you say that you are using now D3D11 for NNEDI3 "NNEDI3/OpenCL now uses D3D11 interop instead of D3D9 interop"
What happens with people like me with old cards that are not compatible with D3D11?
Would it not be possible that madVR would use D3D9 for NNEDI3 is D3D11 is not available?
I hope I am not saying or asking something silly ^^;
And thanks for your hard work =)
madshi
20th September 2015, 21:39
i already used that on a 120 Hz screen this is not usable. the brightness drops way to low. so for proper viewing there has to be a way to counter this. i wouldn't be shocked if the whole gamma curve is not correct anymore.
What you tried is probably simple black frame insertion. There are better ways to do that. E.g. you could "overdrive" the visible frames, and use dark frames instead of black frames. The clipped highlights from the "overdriven" frames could then be added back to the dark frames, so no information is lost. Also you could limit the overdrive/darken to image parts that are moving. I've had many ideas like that, but it's all useless with low refresh rates. So not really worth drooling over atm.
Madshi, you say that you are using now D3D11 for NNEDI3 "NNEDI3/OpenCL now uses D3D11 interop instead of D3D9 interop"
What happens with people like me with old cards that are not compatible with D3D11?
Would it not be possible that madVR would use D3D9 for NNEDI3 is D3D11 is not available?
Have you tried the new build? D3D11 supports D3D9 GPUs, so in theory it could still work. Haven't tested it, though.
CiNcH
20th September 2015, 22:02
Can you retry with v0.89.3? If the problem still occurs with that build, maybe you could create a new log with v0.89.3 for me?
OK, I used DVBViewer Pro in windowed mode (1024x576). So I started the DVBViewer Pro on Sky Atlantic HD (1080i) and switched between this channel and Sky Emotion (576i) and I could not reproduce it easily (or maybe not at all).
I then switched to FSE (1080p50) and it was suddenly easily reproducible...
Then close the media player immediately without switching to another station.
That's a problem because when i am in FSE mode I can't get out of it any longer. I can still switch the channel with the remote and I can hear audio change, but video and OSD are totally frozen. Only with CTRL+ALT+DEL can I get out of FSE, putting the DVBViewer/madVR back to windowed mode. This also makes video playback go on for some reason as if nothing was wrong. So I reproduced the issue, let it run in the bad state for 20s, went back to windowed mode with CTRL+ALT+DEL (which again solved the freeze) and closed the DVBViewer (so no more channel change after the 20s freeze). Hope that's fine with you. Last switch to 1080i broke BTW, image froze on 576i channel with Mini EPG OSD on, audio of the new channel appeared.
madVR - log (https://www.dropbox.com/s/e1stus5kkl8vvoq/madVR%20-%20log.rar?dl=1)
Hope this helps.
Back to 0.88.16 for now ;) .
Dlget
20th September 2015, 22:06
after updating madVR to 0.89.3,now when i open video it plays fine.
But when i got to full screen,player freezes (no madVR debug window,just player freezes & shows wait or close MPC-BE 1.4.5 build 764 beta)
may be something to do with black bar????is it normal that switching from fullscreen windowed mode to windowed mode is slower after blackbar detection.
is there any way to disable black bar detection & that zoom control completely??
2:45am here,so i'll test with settings tomorrow
aufkrawall
20th September 2015, 22:06
Performance with D3D11 interop seems to be fine.
I'm not sure if I could do Adaptive Sharpen on top of 1080p30-> 4k -> WQHD 64 neurons before. Maybe I'm confusing this with the GTX 970 I hard before (now 980), at least it seems to be working well. :)
:thanks: , madshi. It's still nice to have a program that you set&forget and it does the job.
So, it's using nv_d3d11_sharing now on Nvidia?
Wouldn't it be safer to use the khr_d3d10 extension? Maybe they won't ever delete it, as it's the only Khronos extension for this?
But just wild guessing. :)
Hprd
20th September 2015, 22:11
I get a total freeze (have to use task manager to kill player) when using image doubling/quadrupling regardless of the type of scaling that's used. Video completely freezes after 2-3 seconds. Playback is fine without it on. Win 10 x64, gtx 770, NVidia yada yada (not the very lastest driver, but I'm not sure what's really changed in the few updates in the last month and a half? Maybe that is it though) MPC-BE, latest beta (89.2 worked just fine with it).
huhn
20th September 2015, 22:25
1) NNEDI3 now uses a different interop interface, which seems to perform slightly faster for NVidia and quite noticeably faster for AMD. Also it should work with newer NVidia drivers on Windows 10. I haven't tested yet whether the interop problem is gone for AMD, but there's a good chance that it is.
working great on my nvidia. but no performance boost on my AMD r9 270.
so it looks like the interop issue is still there.
Shiandow
20th September 2015, 22:33
Adaptive Sharpen next week. Not sure if there is a new (luma) SuperRes version to update to. But I did plan to work a bit on SuperRes. Might take a bit, though.
I don't think MPDN's version has changed that much since the last time. No matter what I try I keep reverting to the 'old' version since it still seems to give the most natural / accurate result (unless you tweak it for one particular image, but that's not really useful). I'm still searching for a good way to soften the image though.
Dlget
20th September 2015, 22:43
I get a total freeze (have to use task manager to kill player) when using image doubling/quadrupling regardless of the type of scaling that's used.
Hmmm.Same here
both super-xbr & nnedi3 not working in image doubling(not tested nedi)
super xbr works fine with croma upscaling.Nnedi3 not working anywhere not even croma upscaling.
using gtx 960 355.82
if i use nnedi3 for croma up,player freezes after 2-3s even in normal mode & fullscreen
any setting in doubling causes freeze only in fullscreen.(not using FSE & haven't tested that)
aufkrawall
20th September 2015, 22:52
I don't think MPDN's version has changed that much since the last time. No matter what I try I keep reverting to the 'old' version since it still seems to give the most natural / accurate result
I really like the Github version as a kind of sharpening that doesn't brighten things up when resizing from 1080p to WQHD.
Gives me the impression like if there was no upscaling.
But for the near future it's also good to have newer AS version.
kasper93
20th September 2015, 23:43
@madshi: Could you add an option to crop one (or a few) pixel more than black bars have? Cropping black bars leave sharp edge and ringing (1px line) on the video. This can be easily cleaned with "cleanup image borders" feature, but I don't really want to crop video from the sides where there were no black bars before. I hope you know what I mean here.
Thanks for new version it works nicely :)
wanezhiling
21st September 2015, 00:07
* fixed: sometimes video was zoomed in way too much without any reason
Thanks, now works fine with PotPlayer
But I found another 'problem', the players (I tested with latest PotPlayer 1.6.56434 and latest MPC-HC 1.7.9.145) freeze for 2~3 sec when getting to fullscreen, 'fullscreen -> windowed' is fine though.
Well, disabling FSE can get rid of this 'problem'
ps: all applications are using default settings without any touch.
leeperry
21st September 2015, 03:34
13.12 drivers on W7SP1 and first time I ran it in FSE@8bit-ED2 I got a black screen and now mVR crashes instantly with the debugger whining about "amdocl.dll", log sent to your email:
exception class : Exception
exception message : Zugriffsverletzung bei Adresse $633d2981 in Modul 'amdocl.dll'. Lesen von Adresse $0.
4a412bc4 push $4a4ff078 ; 'clEnqueueReleaseD3D11ObjectsKHR'
4a412bc9 push edx
4a412bca call -$421f ($4a40e9b0) ; dynopencl.cpp.GetExtensionProcAddress (madVR.ax)
I don't care about NNEDI3 anymore(as I prefer sxbr25+SR) so if it's only a problem for it then I don't mind if it has to be disabled coz I don't have the platform update installed or don't run the latest AMD drivers(and I don't plan on updating either).
:thanks:
XRyche
21st September 2015, 05:15
You need to double click that batch file when the media player is closed. Then it should work.
First time using debug mode so you'll have to forgive my ignorance. I played a file and then closed MPC-HC. I then open the debug batch file ,giving it admin privileges. Unfortunately it still says it cannot find madVR.ax .
QBhd
21st September 2015, 06:23
Small Bug:
Screen Config is nowhere to be found... unless you create a device profile group.
I'm currently not using the feature, just something I noticed while skimming through the settings.
As for the screen config. Is there any benefit for a user like me that does a 1-1 pixel match on an old plasma with 1024x768 rectangular pixel resolution. I do FSE, and just tell PotPlayer that the output device is "TV-Out 16:9"... Proper AR is maintained this way. Would madVR work more or less if I tinkered with screen config?
QB
Dogway
21st September 2015, 09:10
I lost my long post while testing a 120fps clip, my bad :/
Yes, video runtime for profiles. Short clips are not meant to be "watched" with FSE, NNEDI3, deband, and all the bell and whistles, only need fast access, seek time, start up time... this is specially true if you work with video (NLE, avisynth, YT channel, etc). Even I, with two displays tremble with fear when I want to open/check a small clip on TV, during 6 seconds screen flashes to black to change display mode, then flashes again to black to change to FSE. For small clips I wouldn't mind to run them FS windowed. If this is hard to implement it's fine.
On debanding it depends what type of sources it was tested on, it wouldn't be referential if it was limited to digitally produced pristine HD anime. I'm testing on SD encoded live action where quantization makes a struggle specially on dark areas. But if you think it's fine don't worry.
I was a bit naive, yes 48fps would flicker, I think TV's do use the full refresh rate to interleave BFI.
HDMI spec supports 1080p@120 for v1.4, and mainstream (not cheapo) SmartTV's support 120Hz... I downloaded a 1080p 120FPS video with 1080p120 display mode in madvr and the TV did nothing. Do you mean this is a manufacturer choice? Like the TV's spec doesn't allow anything above 1080p60, even when there's no technical limitation? This also reminds me of lack of DisplayPort on TVs.
On frame drops after switching displays, yes, sometimes it happens even after replay (closing the player previously).
PD: You talked about rendering subs in pause mode. That's also something that annoys me (I work a lot with subtitles, grammar, muxing, syncing, etc), but my opinion don't fix it if it's going to put a strain on resources.
Thanks for the help.
Dlget
21st September 2015, 09:26
MadVR just working fine now....(why?)
It was not working just 4 hours ago here (http://forum.doom9.org/member.php?u=207959).Now it's working just fine magically.
Nnedi3 is ok.Image doubling is ok
michkrol
21st September 2015, 09:28
@madshi, thanks for the new version.
Works fine here (including NNEDI) on Windows 10 (x64), Geforce 750Ti, drivers 355.82 :D
I get a total freeze (have to use task manager to kill player) when using image doubling/quadrupling regardless of the type of scaling that's used. Video completely freezes after 2-3 seconds. Playback is fine without it on. Win 10 x64, gtx 770, NVidia yada yada (not the very lastest driver, but I'm not sure what's really changed in the few updates in the last month and a half? Maybe that is it though) MPC-BE, latest beta (89.2 worked just fine with it).
Hmmm.Same here
both super-xbr & nnedi3 not working in image doubling(not tested nedi)
super xbr works fine with croma upscaling.Nnedi3 not working anywhere not even croma upscaling.
using gtx 960 355.82
I'm on Windows 10 (x64), Geforce 750Ti and it works for me with drivers v355.82.
I did make a clean install while upgrading from drivers v353.49 today, so maybe this has helped somehow?
If you don't want to lose your nvidia's settings because of a clean install, try deleting the content of your %Temp%\NVIDIA Corporation\NV_Cache folder (with media player closed of course) to see if this alone helps. It will delete Nvidia's Shader Cache which is responsible for speeding up subsequent program runs, but sometimes causes problems.
I'm not sure this is a valid solution, but it won't hurt to try and is faster than reinstalling drivers.
@madshi: Could you add an option to crop one (or a few) pixel more than black bars have? Cropping black bars leave sharp edge and ringing (1px line) on the video. This can be easily cleaned with "cleanup image borders" feature, but I don't really want to crop video from the sides where there were no black bars before. I hope you know what I mean here.
I too would welcome an option to crop one (or more) pixel(s) from the borders that got cropped (due to black bars detection), while leaving "uncropped" borders intact.
Meaning, of course, that videos without black borders are left untouched, which is not the case with "cleanup image borders" enabled.
madshi
21st September 2015, 09:39
after updating madVR to 0.89.3,now when i open video it plays fine.
But when i got to full screen,player freezes (no madVR debug window,just player freezes & shows wait or close MPC-BE 1.4.5 build 764 beta)
may be something to do with black bar????is it normal that switching from fullscreen windowed mode to windowed mode is slower after blackbar detection.
is there any way to disable black bar detection & that zoom control completely??
2:45am here,so i'll test with settings tomorrow
I get a total freeze (have to use task manager to kill player) when using image doubling/quadrupling regardless of the type of scaling that's used. Video completely freezes after 2-3 seconds. Playback is fine without it on. Win 10 x64, gtx 770, NVidia yada yada (not the very lastest driver, but I'm not sure what's really changed in the few updates in the last month and a half? Maybe that is it though) MPC-BE, latest beta (89.2 worked just fine with it).
Can the both of you please do this:
1) Activate the madVR debug build.
2) Reproduce the issue.
3) Let the media player stay stuck for 20 seconds.
4) Press Ctrl+Alt+Shift+Pause/Break twice or 3 times with a small delay in between.
5) Use task manager to terminate the frozen media player.
6) On your desktop there should not be a bug log, and hopefully 2-3 freeze reports.
7) Zip all those text files and upload them somewhere. Don't attach to this forum, please.
Thanks.
So, it's using nv_d3d11_sharing now on Nvidia?
Wouldn't it be safer to use the khr_d3d10 extension? Maybe they won't ever delete it, as it's the only Khronos extension for this?
But just wild guessing. :)
Interestingly, nv_d3d11_sharing is 100% identical to the official KHR D3D11 sharing interface. Only the names differ. I don't think NVidia is going to remove this interface. Maybe they'll rename it to KHR at some point. But that's fine with me, too.
khr_d3d10 is not supported by Intel. Intel only supports d3d9 and d3d11 sharing. So I decided to use the latest and greatest in the hope that it has the longest survival time.
working great on my nvidia. but no performance boost on my AMD r9 270.
so it looks like the interop issue is still there.
Hmmmm... I've done some retesting. When doubling a 720p24 file the old build is slightly faster (29ms vs 27ms). However, when doubling a 1080p24 file the new build is noticeably faster for me (57ms vs 68ms). Maybe the interop isn't too much of a problem if you have a fast PCIe 3.0 PC and the amount of pixels which need to be transferred isn't too big?
I suppose we may need feedback from PCIe 1.0 users?
@madshi: Could you add an option to crop one (or a few) pixel more than black bars have? Cropping black bars leave sharp edge and ringing (1px line) on the video. This can be easily cleaned with "cleanup image borders" feature, but I don't really want to crop video from the sides where there were no black bars before. I hope you know what I mean here.
Hmmm... I had been considering either way for the "cleanup image borders" feature. It's true that the black bar borders are more likely to be screwed up than the non-black-bar borders. But aren't non-black-bar borders sometimes screwed up, too? That's why I renamed the option to "cleanup image borders" and made it crop all 4 sides. Originally the option was named "cleanup black bar borders" and would only crop the borders where a black bar was detected.
Of course I could make both options available, but I think there are already "dangerously" many options in the zoom control section. I don't really like the idea to add one more. Furthermore, this is a setting which I was thinking users would setup once and then never change again. If I added both options, that would probably make sense only if users changed it depending on which video they're watching.
So which is the better option to use for "setup once and then forget"? Cleanup image borders? Or cleanup black bar borders?
Any votes from anyone besides kasper93 and me? Personally, I'm fine either way. Wasn't sure myself which one to choose.
Thanks, now works fine with PotPlayer
But I found another 'problem', the players (I tested with latest PotPlayer 1.6.56434 and latest MPC-HC 1.7.9.145) freeze for 2~3 sec when getting to fullscreen, 'fullscreen -> windowed' is fine though.
Well, disabling FSE can get rid of this 'problem'
Is this really a new problem? Can you double check the previous few versions (v0.89.2, v0.89.1, v0.88.21) to check which version exactly has introduced this problem?
Old versions available via download link on the first post of this thread.
No matter what I try I keep reverting to the 'old' version since it still seems to give the most natural / accurate result (unless you tweak it for one particular image, but that's not really useful). I'm still searching for a good way to soften the image though.
Are you still using the "old" Lab/Bicubic version? Or have you changed to the Gaussian version you suggested via PM some weeks ago? You don't like that version, after all?
13.12 drivers on W7SP1 and first time I ran it in FSE@8bit-ED2 I got a black screen and now mVR crashes instantly with the debugger whining about "amdocl.dll", log sent to your email
Does this one fix it?
http://madshi.net/madVR893b.rar (32bit only)
First time using debug mode so you'll have to forgive my ignorance. I played a file and then closed MPC-HC. I then open the debug batch file ,giving it admin privileges. Unfortunately it still says it cannot find madVR.ax .
Don't use admin privileges, just double click it. If that still fails, just do the following manually:
1) rename "madVR.ax" to "madVR [release].ax".
2) rename "madVR [debug].ax" to "madVR.ax".
That's basically all the batch file is doing. When you're done, just undo both renamings.
Screen Config is nowhere to be found... unless you create a device profile group.
Screen config is only meant to be used for projector owners. I didn't anticipate it would be useful for flat panels. Because of that I'm hiding it from flat panel users.
As for the screen config. Is there any benefit for a user like me that does a 1-1 pixel match on an old plasma with 1024x768 rectangular pixel resolution. I do FSE, and just tell PotPlayer that the output device is "TV-Out 16:9"... Proper AR is maintained this way. Would madVR work more or less if I tinkered with screen config?
Oh, good question! So I suppose if you do 1:1 pixel matching and display videos as is, the AR is distorted? If so, probably you could misuse the "anamorphic lens" feature of the screen config page to correct the AR. I'm not sure right now whether you need a "4 / 3" or "3 / 4" stretch factor, though. Try both. One of them should do the trick. In order to get access to the screen config settings, you need to declare your flat panel to be a projector. If this is really useful for you, I might make screen config available for flat panels, too, after all. Or maybe I should add a specific page for flat panels without masking, just with an AR stretch feature?
Yes, video runtime for profiles. Short clips are not meant to be "watched" with FSE, NNEDI3, deband, and all the bell and whistles, only need fast access, seek time, start up time... this is specially true if you work with video (NLE, avisynth, YT channel, etc). Even I, with two displays tremble with fear when I want to open/check a small clip on TV, during 6 seconds screen flashes to black to change display mode, then flashes again to black to change to FSE. For small clips I wouldn't mind to run them FS windowed. If this is hard to implement it's fine.
It's not that hard to implement. The question is how to make script comparisons work correctly. I suppose I could add it as "runtimeInSeconds" or maybe "runtimeInMinutes"?
On debanding it depends what type of sources it was tested on, it wouldn't be referential if it was limited to digitally produced pristine HD anime. I'm testing on SD encoded live action where quantization makes a struggle specially on dark areas. But if you think it's fine don't worry.
It was tested on all kinds of SD and HD sources. Many of them Anime, because that's where banding occurs most often, but also on filmed content / life action.
HDMI spec supports 1080p@120 for v1.4, and mainstream (not cheapo) SmartTV's support 120Hz... I downloaded a 1080p 120FPS video with 1080p120 display mode in madvr and the TV did nothing. Do you mean this is a manufacturer choice? Like the TV's spec doesn't allow anything above 1080p60, even when there's no technical limitation? This also reminds me of lack of DisplayPort on TVs.
I'm not aware of a single TV or projector which supports 120Hz input, but I'm sure some models will support it. It's very rare, though. HDMI in theory also supports 111Hz or 88Hz. Bandwidth issues aside, the key problem is what the firmware of the TV/projector supports. And most manufacturers don't bother implementing support for 120Hz. And why should they? It would cost them development resources which 99.99% of all users wouldn't ever use. Furthermore, with a 120Hz input they would probably have to extend the firmware to automatically disable all sorts of algorithms, like their own black frame insertion, motion interpolation etc. So I understand that they don't bother supporting high refresh rate input.
The situation may change if some important future gaming console is fast enough for 120Hz rendering. Or if UHD at some point supports 120Hz content.
MadVR just working fine now....(why?)
It was not working just 4 hours ago here (http://forum.doom9.org/member.php?u=207959).Now it's working just fine magically.
Nnedi3 is ok.Image doubling is ok
Not sure what happened. But sounds good so far. Hope it stays that way?
@madshi, thanks for the new version.
Works fine here (including NNEDI) on Windows 10 (x64), Geforce 750Ti, drivers 355.82 :D
Glad to hear that!
I too would welcome an option to crop one (or more) pixel(s) from the borders that got cropped (due to black bars detection), while leaving "uncropped" borders intact.
Meaning, of course, that videos without black borders are left untouched, which is not the case with "cleanup image borders" enabled.
Ok, two votes for that now. Will see if anybody votes the other way. Otherwise I'll change it for the next build.
OK, I used DVBViewer Pro in windowed mode (1024x576). So I started the DVBViewer Pro on Sky Atlantic HD (1080i) and switched between this channel and Sky Emotion (576i) and I could not reproduce it easily (or maybe not at all).
I then switched to FSE (1080p50) and it was suddenly easily reproducible...
That's a problem because when i am in FSE mode I can't get out of it any longer. I can still switch the channel with the remote and I can hear audio change, but video and OSD are totally frozen. Only with CTRL+ALT+DEL can I get out of FSE, putting the DVBViewer/madVR back to windowed mode. This also makes video playback go on for some reason as if nothing was wrong. So I reproduced the issue, let it run in the bad state for 20s, went back to windowed mode with CTRL+ALT+DEL (which again solved the freeze) and closed the DVBViewer (so no more channel change after the 20s freeze). Hope that's fine with you. Last switch to 1080i broke BTW, image froze on 576i channel with Mini EPG OSD on, audio of the new channel appeared.
madVR - log (https://www.dropbox.com/s/e1stus5kkl8vvoq/madVR%20-%20log.rar?dl=1)
Hope this helps.
Back to 0.88.16 for now ;) .
Thanks. I've read through the log for almost an hour now. I'm pretty sure I found the right place to look at, but according to the log, madVR is happily receiving DXVA decoded frames from the decoder, deinterlacing them, rendering them, and presenting them to Direct3D for those 20 seconds. I can't find any indication that something would be wrong in the log.
Can you give me a few more details about how it looks? Does the image of the new station appear at all? Or are you getting stuck with the the last frame of the previous channel? If the new station does appear, does it play fine for a short while? Or do you just see one image from the new station and it gets stuck immediately?
What happens if you switch to software decoding (just as a test, of course)? Maybe it's not madVR that is frozen but the decoder, sending the same frame again all the time? A wild guess, obviously. Do the OSDs (madVR's Ctrl+J and DVBViewer's) still work? Or are they frozen, too?
CiNcH
21st September 2015, 09:51
Can you give me a few more details about how it looks? Does the image of the new station appear at all? Or are you getting stuck with the the last frame of the previous channel? If the new station does appear, does it play fine for a short while? Or do you just see one image from the new station and it gets stuck immediately?
In the above log it happened when switching from the 576i channel to the 1080i channel. But the 1080i channel did not appear. There is a still image of the previous channel. New channel does not appear, only audio. I can't get out of FSE anymore by doubleclicking. I have to press CTRL+ALT+DEL and bring the Task-Manager to front. Then madVR is thrown out of FSE and video suddenly appears.
What happens if you switch to software decoding (just as a test, of course)? Maybe it's not madVR that is frozen but the decoder, sending the same frame again all the time? A wild guess, obviously.
I never experienced that issue before. It is also easily reproducible with avcodec (SW) mode.
Do the OSDs (madVR's Ctrl+J and DVBViewer's) still work? Or are they frozen, too?
Totally frozen. No DVBViewer OSD, no madVR OSD. Not even doubleclicking gets me out of FSE. Only CTRL+ALT+DEL and running the Task-Manager kicks madVR out of FSE and makes video immediately appear again.
romulous
21st September 2015, 10:00
For image quality comparisons you should be using 100% view, anyway, shouldn't you?
For me, I run everything at 1280x720, regardless of resolution (and I don't do image quality comparisons). So having madVR tell me that my player is doing 1280x720 was very handy :(
Serhiyko
21st September 2015, 10:40
Ah yes. Newer madVR builds don't fully rerender the paused video frame all the time, to save resources. If you use the built-in subtitle renderer then madVR does not know that you changed the subtitle track, so I don't know that I need to rerender the video frame. I'm not sure if I can solve this without pushing GPU power through the roof again in paused mode. And frankly, I don't think this is important enough to make compromises with high GPU power in paused mode.
What can I do then?
Are you using DXVA decoding and/or DXVA scaling?
Don't think so
Shiandow
21st September 2015, 12:01
Are you still using the "old" Lab/Bicubic version? Or have you changed to the Gaussian version you suggested via PM some weeks ago? You don't like that version, after all?
Well I liked it for one particular image (the castle image) but after trying lots of other images I'm not so sure. I'm not using Lab anymore though. So far I've failed to see any difference between Lab and gamma light, even when I've artificially enhanced the image. I am still using linear light for downscaling though.
QBhd
21st September 2015, 12:02
Oh, good question! So I suppose if you do 1:1 pixel matching and display videos as is, the AR is distorted? If so, probably you could misuse the "anamorphic lens" feature of the screen config page to correct the AR. I'm not sure right now whether you need a "4 / 3" or "3 / 4" stretch factor, though. Try both. One of them should do the trick. In order to get access to the screen config settings, you need to declare your flat panel to be a projector. If this is really useful for you, I might make screen config available for flat panels, too, after all. Or maybe I should add a specific page for flat panels without masking, just with an AR stretch feature?
I'll tinker around with putting PotPlayer's output device back to auto (it will assume TV is a 4:3 screen) and try some of the screen config factors to see if it could compensate for the mismatched AR's.
Personally I do not need this since PotPlayer allows you to change the output device AR, but it maybe useful for people who can't (or don't know how to) do this.
QB
kasper93
21st September 2015, 12:20
Of course I could make both options available, but I think there are already "dangerously" many options in the zoom control section. I don't really like the idea to add one more. In fact I was thinking about dropdown menu to control "crop black bars" feature. Where user could select if it must be exact crop or should crop N lines more. But I fully understand that too many options is also not a good thing.
So which is the better option to use for "setup once and then forget"? Cleanup image borders? Or cleanup black bar borders? For me personally option to set up and forget is "cleanup black bar borders", because it would leave videos without borders untouched. HQ content rarely have messed up borders. But frankly those features have different purpose imo. "Cleanup image borders" might be very useful for DVD or SDTV, where borders are often messed up. If I were forced to pick one, I would probably stick with "Cleanup image borders". Though like I said I would enable it only when necessary.
leeperry
21st September 2015, 13:35
Does this one fix it?
http://madshi.net/madVR893b.rar (32bit only)
Nope, still a black screen and a debugger window:
exception class : Exception
exception message : Zugriffsverletzung bei Adresse $633d2981 in Modul 'amdocl.dll'. Lesen von Adresse $0.
4a412bc0 push $4a4ff078 ; 'clEnqueueReleaseD3D11ObjectsKHR'
4a412bc5 push edx
4a412bc6 call -$421b ($4a40e9b0) ; dynopencl.cpp.GetExtensionProcAddress (madVR.ax)
huhn
21st September 2015, 13:55
Hmmmm... I've done some retesting. When doubling a 720p24 file the old build is slightly faster (29ms vs 27ms). However, when doubling a 1080p24 file the new build is noticeably faster for me (57ms vs 68ms). Maybe the interop isn't too much of a problem if you have a fast PCIe 3.0 PC and the amount of pixels which need to be transferred isn't too big?
I suppose we may need feedback from PCIe 1.0 users?
i can force PCIe 1.1 on my board but there where no real difference between both version. i can do a better comparison later.
even GPU-z clearly said i'm at PCIe 1.1.
FreeFall
21st September 2015, 15:52
madshi, just tested 0.89.3
I tried the option "If there are large black bars zoom them away completely", removes the black bars but zooms in and cuts off the subtitles. With the Blu-Ray disc sample using notify the media player about cropped bars and with the crop black bars option enabled works (removes the pillarboxing and keeps the subtitles intact) when using stretch to window.
However the above settings don't work for the DVD sample I uploaded (subtitles positioned in the horizontal black bars), the subtitles get cut off. Using the option keep black bars visible if they contain subtitles works around that problem. The forever setting doesn't seem to be working (black bars still get cropped), all the other options are ok.
I'd like to be able to crop the black bars and keep the subtitles visible without them being stretched, cut off or zoomed. A simple crop method without any zoom / aspect ratio correction applied should work, similar to using Avisynth to crop the video before re-encoding.
Thanks.
ikakun
21st September 2015, 16:04
This latest madvr version is fast on nnedi3 for me. I can now increase all of my profiles settings with nnedi3 16 neurons, to 64 neurons.
Also, I'm using the latest amd beta driver.
EDIT: And my GPU is at PCI-E 1.1
everlast4291987
21st September 2015, 16:05
@madshi. Thank You so much for the NNEDI3 fix. It works well I have no more freezes scaling a 512x384 movie to 3840x2160. My i5 2500k can finally rest instead of being stuck @100% while playing the same file. Thank you so much for this update. :thanks:
My GPU is EVGA GTX 980ti.
My OS Windows 10 x64
My GPU Drivers 355.82
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.