View Full Version : madVR - high quality video renderer (GPU assisted)
Sm3n
11th April 2015, 01:12
thank you for the update.
nevcairiel
11th April 2015, 02:54
Video content is exactly the same any any other content once we have frames of video information. All madVR would need to do is present frames when it thinks they should be displayed. madVR could do the doubling too, if madshi wanted to support FreeSync as well.
No, video content is quite distinctly different to content actually created/rendered on-the-fly (like a game).
Videos are all pre-rendered and pre-timed. To properly present them on such a "variable sync" system, you would for one need a super precise clock, since you have no Vsync that you can use for this purpose, and hope that the GPU and display actually present them without a varying delay (which a game could easily and automatically compensate for).
Additionally, you cannot have any "drop" protection. madVR prepares and presents several frames in advance so that a small hiccup in the system wouldn't be noticed. If you cannot present in advance (because the GPU would display them immediately without a fixed sync) you lose this protection, and you may notice this.
All in all, you lose quite a bunch of things that every video renderer leverages today to get smooth and stable playback.
Noone is saying that you couldn't build a video renderer specifically for this, we're only saying that no existing video renderer would be equipped to do this without a major design shift (and that its really not worth it when you can play videos at 100-144 Hz instead, plus this feature only being available in "gaming" screens)
andybkma
11th April 2015, 03:10
Hi madshi, I need to report that 87.19 has a playback bug. When any video starts (any format), it is frozen for a split second then plays quick catchup (plays fast for a another split second) then will start to play normally. I went from 87.17 to 87.19 and 87.17 didn't have this problem so this is something new that was introduced in the last two versions. Thank you :-)
Player is Zoom Player, splitters/decoders are everything LAV
SecurityBunny
11th April 2015, 07:47
I also seem to be experiencing playback issues since updating.
When watching content in windowed mode or windowed fullscreen, occasionally the video hiccups for a few frames causing the audio and video to stutter. Looking at the OSD stats when it occurs, the render queue drops to 7-8 / 20 from formerly 19-20 / 20. It stays at 7-8 until the video is paused and started again. The rendering ms time continues to slowly increment indefinitely until paused as well. If left untouched, eventually causing dropped frames due to the rendering time being greater than the movie frame interval.
http://i.imgur.com/kctWgjt.png
As far as I'm aware of, using MPC-HC 1.7.8.123 with madVR .87.17 was functioning fine without this issue. Since updating to MPC-HC 1.7.8.152 and madVR .87.19, this issue occurs frequently in windowed playback. Using fullscreen exclusive, this issue does not occur. However, I very much like windowed fullscreen over exclusive. :(
ryrynz
11th April 2015, 08:51
Sounds like you guys have the same issue, you could try 0.87.18 (http://www.videohelp.com/download/madVR08718.zip) and see if it happens with that, might save madshi some time.
andybkma
11th April 2015, 08:59
Hi madshi, I need to report that 87.19 has a playback bug. When any video starts (any format), it is frozen for a split second then plays quick catchup (plays fast for a another split second) then will start to play normally. I went from 87.17 to 87.19 and 87.17 didn't have this problem so this is something new that was introduced in the last two versions. Thank you :-)
Player is Zoom Player, splitters/decoders are everything LAV
87.18 same problem, per ryrynz's suggestion.
madshi
11th April 2015, 09:04
@andybkma, and going back to 87.17 immediately fixes the problem? Could you please double check, just to be sure? What happens if you enable the "delay playback start" option?
@SecurityBunny, could you please separately try 87.17 vs 87.19, and the old vs the previous MPC-HC version, so that we can be sure which update was reponsible for the new problem? And if you find that it's madVR which caused the problem, please check 87.18, so that I know for sure where to look. Thanks.
andybkma
11th April 2015, 09:32
@andybkma, and going back to 87.17 immediately fixes the problem? Could you please double check, just to be sure? What happens if you enable the "delay playback start" option?
Yes, going back to 87.17 immediately fixes the problem, same exact settings.
Please explain more about what you want me to do with the "Delay playback start until render queue is full" option which I have unchecked. Do you want me to enable this option in 87.18 and see if the problem persists?
madshi
11th April 2015, 09:38
Yes, please enable that option with v0.87.19 and check if that works around the problem. Could you please also double check with v0.87.13? There's a change I implemented in v0.87.14 (IIRC) which I reverted in v0.87.18. I wonder if that's that change which is reponsible. If it is, then the same problem should occur with v0.87.13.
andybkma
11th April 2015, 10:01
Yes, please enable that option with v0.87.19 and check if that works around the problem. Could you please also double check with v0.87.13? There's a change I implemented in v0.87.14 (IIRC) which I reverted in v0.87.18. I wonder if that's that change which is reponsible. If it is, then the same problem should occur with v0.87.13.
1) Okay so in 87.19 I enabled the "Delay playback start until render queue is full" option. Same bug as reported. It just takes longer until the vid starts playing (black screen until a picture is displayed) but when the picture does finally appear it is paused for a split second, then plays very fast for a split second, then plays normally. The problem just seems to be delayed by enabling that "delay playback start" option.
2) Using 87.13, no problems
huhn
11th April 2015, 10:03
this is about a video speed up issue so i have to ask.
do you use SM and a 3D LUT?
andybkma
11th April 2015, 10:05
this is about a video speed up issue so i have to ask.
do you use SM and a 3D LUT?
Nope, sure don't
madshi
11th April 2015, 10:16
Ok, two more questions:
1) This is not about DVD playback, right? This also occurs with other files?
2) Are you using anything DXVA (deinterlacing, scaling, native decoding)? If so, can you try turning that off. Does the problem still occur?
andybkma
11th April 2015, 10:26
Ok, two more questions:
1) This is not about DVD playback, right? This also occurs with other files?
2) Are you using anything DXVA (deinterlacing, scaling, native decoding)? If so, can you try turning that off. Does the problem still occur?
1) I don't play DVDs, only video files. The problem occurs with all video files no matter the container or codec
2) Am doing nothing like that. Just very simple decoding with LAV Splitter to LAV Decoder to mVR as the renderer. Seeking is fine, it only happens upon intial video start.
Something causing this was introduced in 87.18 but I know you know that already ;-)
nijiko
11th April 2015, 12:32
Support will come, it's on Madshi's to do list. I do believe he has some other features he wishes to add first.. But fingers crossed we'll see a 64 bit version this year.
When?
First of all, it's a good news to hear that. It's very necessary now. Is there any alpha version?
Yes, maybe sooner rather than later now but no ETA. :)
Hope it's not too late.
flashmozzg
11th April 2015, 14:16
With latest madVR I started to experience occasional hangs (mostly after going out(in?) of FSE mode).
madVR tray icon responds fine I can even make it continue to play a video through it (though only sound is heard as mpc-hc windows is "not responding").
EDIT: happened again. Seems to be the issue of going from FSE to windowed after certain time spent in FSE (1-3 min). Thoguht it's not reliably reproducible.
Anime Viewer
11th April 2015, 18:51
Nvidia users experiencing problems (In particular people with Optimus systems who reported black screen issues) in madVR may benefit from updating to the 350.05 drivers (which includes an update from OpenCL 1.1 to 1.2).
http://nvidia.custhelp.com/app/answers/detail/a_id/3647
Thanks goes to Garteal for sharing the information (http://forum.doom9.org/showthread.php?p=1717065#post1717065) and link.
huhn
11th April 2015, 21:19
sadly they have broken openCL in this driver...
luk008
11th April 2015, 22:33
I see that most people recommend CR + AR + LL as the best image downscale algorithm. Wouldn't be better to use Mitchell-Netravali or even Lanczos instead?
People recommend linear light to downscale but not for upscale. What's the reason of this? Thanks.
With latest madVR I started to experience occasional hangs (mostly after going out(in?) of FSE mode).
madVR tray icon responds fine I can even make it continue to play a video through it (though only sound is heard as mpc-hc windows is "not responding").
EDIT: happened again. Seems to be the issue of going from FSE to windowed after certain time spent in FSE (1-3 min). Thoguht it's not reliably reproducible.
I have the same problem here with madVR v0.87.19 (It's fine with 0.87.18). These hangs sometimes make the AMD Catalyst driver to crash.
huhn
11th April 2015, 22:57
I see that most people recommend CR + AR + LL as the best image downscale algorithm. Wouldn't be better to use Mitchell-Netravali or even Lanczos instead?
People recommend linear light to downscale but not for upscale. What's the reason of this? Thanks.
the is no "best" just use what looks best to your eyes.
LL adds a ton of ringing when used for upscaler and it's way to sharp. if you ask me.
seiyafan
12th April 2015, 01:42
I have a 1440p monitor so when I play 1080p movies it first upscales using Nnedi32 then downscales with CR AR. Do you think this two-step process is still better than using a one-step such as Jinc3 AR?
ryrynz
12th April 2015, 02:56
I have a 1440p monitor so when I play 1080p movies it first upscales using Nnedi32 then downscales with CR AR. Do you think this two-step process is still better than using a one-step such as Jinc3 AR?
Better is personal preference. Why not just compare it yourself and determine if you like the end result better? All resizers have advantages and disadvantages but many would prefer using NNEDI3.
Anime Viewer
12th April 2015, 03:11
sadly they have broken openCL in this driver...
In what way? I haven't noticed any problem with it.
Yvese
12th April 2015, 07:44
Hoping someone can help me with an issue:
I have a 1080p TV connected to my PC's GPU ( r9 290 ) via HDMI. I have 2 pc monitors also connected to the GPU, with 1 more monitor connected to my IGP ( i7 4770k ).
My problem is madvr scales my videos/movies to 720p rather than 1080p ( it shows 720p for target rectangle ). The resolution is correctly set on windows and my GPU driver. The scaling works correctly if I move MPC to my other monitors ( 1440p, 1080p and 1200p monitors ).
I've tried reinstalling mpc+madvr but that didn't work. Hoping someone has come across this before.
Thanks!
huhn
12th April 2015, 08:10
In what way? I haven't noticed any problem with it.
you can read about it here:
http://bugs.madshi.net/view.php?id=250&PHPSESSID=a4c73aa2fb2fb1d5a0e4544e7b8f3b23
this error diffusion issue was fixed with driver 349.xx (350.5 is the 106 driver from this driver branch)
the talk about the openCL issue start at 848
here an example http://i.imgbox.com/AxRKYBuL.png
nvidia has reproduce the issue and maybe all maxwell GPUs are not affected, there 750 wasn't affected.
Hoping someone can help me with an issue:
I have a 1080p TV connected to my PC's GPU ( r9 290 ) via HDMI. I have 2 pc monitors also connected to the GPU, with 1 more monitor connected to my IGP ( i7 4770k ).
My problem is madvr scales my videos/movies to 720p rather than 1080p ( it shows 720p for target rectangle ). The resolution is correctly set on windows and my GPU driver. The scaling works correctly if I move MPC to my other monitors ( 1440p, 1080p and 1200p monitors ).
I've tried reinstalling mpc+madvr but that didn't work. Hoping someone has come across this before.
Thanks!
do you have a screen from the OSD ?
does the video have black boarders on your TV?
what are your display mode settings?
have you tried to reset madVR settings? reinstalling madVR doesn't do that try the rest before please.
sexus
12th April 2015, 09:19
according to that ticket as its still open, the issue with opencl is yet to be fixed with a new driver release by nvidia devs
huhn
12th April 2015, 09:25
according to that ticket as its still open, the issue with opencl is yet to be fixed with a new driver release by nvidia devs
yes openCL is broken with 350.05
but the ticket it self is about error diffusion that uses directcompute and that's fixed with 350.05
sexus
12th April 2015, 09:28
any eta on the fix?
huhn
12th April 2015, 10:00
any eta on the fix?
i don't know maybe the next new branch drivers from nvidia.
aufkrawall
12th April 2015, 12:08
I don't notice any OpenCL problems with 350.05 & GM204 on Windows 8.1. Maybe a Kepler only bug?
Regarding NNEDI3 for 1080p -> 1440p: There is almost no visible difference between it and Jinc3 AR.
You will also have to define scrips to be able to play 1080p60 videos fluidly etc.
I'd also suggest to not use NNEDI3 for chroma, it can give terrible artifacts like red exit signs beeing not readable anymore etc.
Could someone provide me with a picture where NNEDI3 image doubling really fails? It's said to have problems with structures like fine vegetation, but I never found anything distracting with it for myself when using Jinc3 AR for chroma.
huhn
12th April 2015, 12:16
I don't notice any OpenCL problems with 350.05 & GM204 on Windows 8.1. Maybe a Kepler only bug?
http://forum.doom9.org/showpost.php?p=1717180&postcount=28784
Regarding NNEDI3 for 1080p -> 1440p: There is almost no visible difference between it and Jinc3 AR.
it has the biggest effect on aliased sources. the good think about nnedi3 is it doesn't create any ringing.
I'd also suggest to not use NNEDI3 for chroma, it can give terrible artifacts like red exit signs beeing not readable anymore etc.
sounds like a bug do you have a sample of this exit sign?
there was a bug with downscaling where things can go totaly wrong.
Could someone provide me with a picture where NNEDI3 image doubling really fails? It's said to have problems with structures like fine vegetation, but I never found anything distracting with it for myself when using Jinc3 AR for chroma.
it never really fails it can create strange patterns in grass and things like that but nothing like a totally fail.
aufkrawall
12th April 2015, 12:35
http://forum.doom9.org/showpost.php?p=1717180&postcount=28784
Sorry, I finally managed to scroll down... :(
it has the biggest effect on aliased sources. the good think about nnedi3 is it doesn't create any ringing.
Aliased sources also look aliased with NNEDi3. ;)
With 1080p -> 1440p, Jinc3 AR barely introduces ringing and aliasing artifacts.
sounds like a bug do you have a sample of this exit sign?
there was a bug with downscaling where things can go totaly wrong.
I should be able to find it again.
it never really fails it can create strange patterns in grass and things like that but nothing like a totally fail.
Yes, I was asking because I haven't noticed such patterns yet.
I'm aware of the castle picture and its weird window shapes, but if I had encountered such artifacts, I failed to perceive them without a comparison to Jinc3 AR.
huhn
12th April 2015, 12:54
Aliased sources also look aliased with NNEDi3. ;)
With 1080p -> 1440p, Jinc3 AR barely introduces ringing and aliasing artifacts.
nnedi3 is working like an AA filter it can remove a ton of aliasing.
here this pixel art PC games shows some issue and shows how nnedi3 is working as an AA filter:
http://www.file-upload.net/download-10535096/schweif_000-001.mkv.html
i'm pretty bad which these file hosting things. hope it works
now i'm missing my johann krauser 2...
aufkrawall
12th April 2015, 13:28
This source is extremely small, I almost can't perceive any details at original size.
I think this not compareable to 1080p -> 1440p. I did some tests with it, also with not so great sources, and there was hardly any difference to Jinc3 AR.
Keep in mind that you throw away some amount of detail due to downscaling.
huhn
12th April 2015, 13:49
but scaling this with jinc3 or nnedi3 is day night.
and aliasing is kind of always the same just take a computer game without active AA and scale it.
rasterisation always creates pixel big aliasing the resolution is not import you simply doesn't notice this at higher resolution anymore.
this source is not important at all but it shows very well the potential difference between jinc3 and nnedi3.
aufkrawall
12th April 2015, 14:07
It's only day night difference if the scaling factor is high, which is not the case with 1080p -> 1440p.
Jinc3 AR chroma + luma:
http://abload.de/thumb/jinc38gbdx.png (http://abload.de/image.php?img=jinc38gbdx.png)
Jinc3 AR chroma + NNEDI3 64 image doubling (CR AR LL downscaling):
http://abload.de/thumb/nnedi364bxzsa.png (http://abload.de/image.php?img=nnedi364bxzsa.png)
huhn
12th April 2015, 14:13
with the link video it is day night not in general.
i personally never use it for 720->1080 only for x2 scaling without downscaling.
aufkrawall
12th April 2015, 14:20
Sure, it looks totally amazing with lowres content. With artificial content like cartoons the difference is enormous, no question.
I really like how it doesn't introduce any aliasing and ringing. But isn't this because they simply don't exist, instead of filtering them away?
madshi
12th April 2015, 14:37
1) I don't play DVDs, only video files. The problem occurs with all video files no matter the container or codec
2) Am doing nothing like that. Just very simple decoding with LAV Splitter to LAV Decoder to mVR as the renderer. Seeking is fine, it only happens upon intial video start.
Something causing this was introduced in 87.18 but I know you know that already ;-)
Ok, I found the change which caused the problem. I'll remove the change, I just hope it won't break Optimus compatability again... :(
With latest madVR I started to experience occasional hangs (mostly after going out(in?) of FSE mode).
madVR tray icon responds fine I can even make it continue to play a video through it (though only sound is heard as mpc-hc windows is "not responding").
EDIT: happened again. Seems to be the issue of going from FSE to windowed after certain time spent in FSE (1-3 min). Thoguht it's not reliably reproducible.
I have the same problem here with madVR v0.87.19 (It's fine with 0.87.18). These hangs sometimes make the AMD Catalyst driver to crash.
Can you guys please create a freeze report (Ctrl+Alt+Shift+Break) and upload it somewhere (not here) and link here, so that I can look at it?
I have a 1080p TV connected to my PC's GPU ( r9 290 ) via HDMI. I have 2 pc monitors also connected to the GPU, with 1 more monitor connected to my IGP ( i7 4770k ).
My problem is madvr scales my videos/movies to 720p rather than 1080p ( it shows 720p for target rectangle ).
So madVR correctly renders to the desired target rectangle? If that's the case then it's not madVR which is at fault here. The media player defines the target rectangle. madVR just obeys.
iSunrise
12th April 2015, 14:41
nnedi3 is working like an AA filter it can remove a ton of aliasing.
NNEDI3 is the sharpest and quite comfortably most accurate scaling algorithm madVR offers, as such, it should be exactly the opposite.
NNEDI3 is as close to a perfect scaler (in powers of 2) as you can get without investing even more for performance. It does the least amount of filtering, excluding nearest neighbour, which NNEDI3 almost approaches, but without all the negatives that nearest neighbour has.
That's the reason why it is especially useful for low resolution content.
NNEDI3 still has artifacts though, which could probably be eliminated with additional optimizations, like madshi's AR algorithm. Since we never could test this though, this is only an assumption.
huhn
12th April 2015, 14:44
https://www.youtube.com/watch?v=0691zsXWbhA
it's AA like crazy and that's something you usually want from a resizer but it is 100% reducing aliasing.
sexus
12th April 2015, 15:56
ok ive found a bug with the latest build , madvrs playback info overlay ctrl+j shows jinc3 AR on upscaler as lanczos 3 AR oddly enough all other upscalers show properly when selected instead of falsely showing as lanczos 3 AR , please fix this , thanks
madshi
12th April 2015, 16:07
ok ive found a bug with the latest build , madvrs playback info overlay ctrl+j shows jinc3 AR on upscaler as lanczos 3 AR oddly enough all other upscalers show properly when selected instead of falsely showing as lanczos 3 AR , please fix this , thanks
Please show a screenshot of the ctrl+j OSD.
dansrfe
12th April 2015, 16:07
Exiting MPC-HC window directly (Alt+F4) from exclusive mode on an Optimus system causes the screen to show jagged white lines on a blue background. I'm not sure if a freeze report would help. I'm using a copy of MPC-HC which is set to NVidia in the NVidia control panel.
madshi
12th April 2015, 16:10
Exiting MPC-HC window directly (Alt+F4) from exclusive mode on an Optimus system causes the screen to show jagged white lines on a blue background. I'm not sure if a freeze report would help. I'm using a copy of MPC-HC which is set to NVidia in the NVidia control panel.
Screenshot? Sounds like a driver issue, though.
Yvese
12th April 2015, 17:00
do you have a screen from the OSD ?
does the video have black boarders on your TV?
what are your display mode settings?
have you tried to reset madVR settings? reinstalling madVR doesn't do that try the rest before please.OSD: http://i.imgur.com/UeaRXZO.jpg
Here's a screenshot showing the res in windows: http://i.imgur.com/tbfSZw2.jpg
The only black borders are from the movies itself. On the desktop the whole screen is filled. For display modes I don't use any. As for resetting madvr not sure how to unless right clicking screen -> renderer settings -> reset -> reset to default renderer settings counts.
sexus
12th April 2015, 17:26
Please show a screenshot of the ctrl+j OSD.
here
http://anonfiles.co.uk/image.php?di=Q5R6
btw what does limited range mean? is this connected to the 16-235 range issue with nvidia drivers? and if so ive installed the 347.52 drivers which are supposed to have fixed this long standing nvidia bug
sneaker_ger
12th April 2015, 17:32
"limited range (best guess)" refers to the source file's range. Since 99% of all sources are indeed limited range this is completely normal. It is not related to your GPU/system.
sexus
12th April 2015, 17:44
ah i see , good to know
huhn
12th April 2015, 18:00
OSD: http://i.imgur.com/UeaRXZO.jpg
Here's a screenshot showing the res in windows: http://i.imgur.com/tbfSZw2.jpg
The only black borders are from the movies itself. On the desktop the whole screen is filled. For display modes I don't use any. As for resetting madvr not sure how to unless right clicking screen -> renderer settings -> reset -> reset to default renderer settings counts.
can you upload the settings.bin from the madVR folder?
this looks very strange can you show me your display mode you find these under: devices "name of the device" display modes.
if you haven't set anything there you can ignore this just try to reset madVr settings by going in to the madVR folder and running the restore default settings.bat.
retangle is usually an an order from the play you can reset mpc-hc by going to options -> Micellaneous -> settings management reset.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.