Jump to content


Photo

What is the best video Renderer?


  • Please log in to reply
21 replies to this topic

#1 Lobo

Lobo

    Adept

  • Members
  • PipPipPip
  • 73 posts

Posted 18 March 2011 - 03:03 PM

Ok, I admit I am a few fries shy of a happy meal, but what video renderer should I use and why. I know their may be different opinions so we will have duel at sunrise, lol. Thanks in advance.

#2 magic144

magic144

    Master

  • Members
  • PipPipPipPipPip
  • 549 posts

Posted 18 March 2011 - 04:59 PM

I'd be interested in hearing this discussion too.

I've always used EVR ever since Vista and never had an issue with it (or a reason to want anything else/more).

#3 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 19 March 2011 - 12:38 AM

Edit: This post is now out of date - it is fine to still read for context, but for the most current information, see post #15 below (http://forum.inmatri...698)

Here are my thoughts, for what they are worth.

The old VMR7/VMR9 renderers - They work, but that's about all that can be said for them.

For me, that leaves the race between 3: Haali's, madVR and EVR. Here I have used '+' to indicate something good, '-' to indicate something bad.

EVR:
+If you want high quality subtitles (and this is important for some people), use EVR.
+Video quality is pretty good.
-If you use XP however, EVR is only available with a certain .NET installation (think it is at least 3.5 SP1).

Haali's:
+I like this one for the colour reproduction and up until recently, was the renderer I used.
-Not actively developed anymore, as Haali now works for CoreAVC.
-I really dislike the built-in (and unable to be disabled) resizing thing it does (if the renderer detects that the player window will be within a certain distance of the edge of the monitor, it resizes the video player window to half). Very irritating, but Haali designed it to do exactly this, and as it was his renderer and he was unwilling to change it (it was the most commonly requested change over on Doom9), you have to live with it if you want to use it.
-Has some problems when used with Zoom Player and FLV files (at least on my system, problem does not affect other players such as MPC-HC, again on my system).

madVR:
+Meant to be the best picture quality.
-Hardware requirements are higher than for any other renderer as it works with uncompressed video only.
+Being actively developed.
+Has 'exclusive mode', which helps improve video playing quality.
-No subtitle support as yet (have to use ffdshow or vobsub or similar).
-DVD playing under Win 7 not available due to a known error.
-No screencapture facility as yet either (have to use the Windows printscreen key).
-Only accepts YV12 and NV12 input, which for me is a problem, as I have a lot of older MPEG2 content, and the MPEG2 decoder does not output in either of those formats, which means madVR won't play them.

If it wasn't for the problems, madVR would be my choice because it focuses on quality above all else. However, as it is, I run two separate Zoom installs - the main one using EVR (the problems with Haali+Zoom+FLV files finally forced me to switch recently) and the secondary one using madVR. I use the madVR one when I play hi-def content, the EVR one for the rest of the stuff.

Regards,

ehat

Edited by ehathgepiurhe, 06 September 2012 - 11:26 AM.


#4 magic144

magic144

    Master

  • Members
  • PipPipPipPipPip
  • 549 posts

Posted 19 March 2011 - 01:02 AM

Thanks for the bullet-points ehat

Can you describe in what way the 'quality' of madVR is 'better' than EVR - I watch all content (SD & HD) with EVR right now and I don't see any issues - is it possible to put into words??!

You say madVR doesn't have subtitle support - I thought all subtitle rendering was done by a separate filter anyway (e.g. VSFilter, ffdshow, etc) - what renderers take subtitles directly??
Along the same kind of thinking, you say madVR only takes raw video - do other renderers take compressed video as input?? Again, I thought the video codec handled all that and the renderers always required 'raw' video...? Are there any issues with madVR and DXVA??

Thanks :-)

#5 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 19 March 2011 - 02:49 AM

Thanks for the bullet-points ehat


No worries :) Ok, one point at a time (and I'm not a world expert on video renderers, so if anyone notices anything I've said is wrong, please feel free to correct it):

Can you describe in what way the 'quality' of madVR is 'better' than EVR - I watch all content (SD & HD) with EVR right now and I don't see any issues - is it possible to put into words??!


With EVR and madVR, the difference is subtle. I took 2 different clips, one HD (a Blu-Ray disk actually) and the other SD (a clip I found on YouTube). With both clips, I opened each in a Zoom instance using EVR, and another Zoom instance using madVR. I then skipped to the same frame in both instances (surprisingly difficult, Zoom does not match frame numbers when different renderers are in use I've discovered!) and took some screenshots. With the HD content, I noticed no real differences. With the SD content (SD content is zoomed to 150% in Zoom Player, the HD content was just at 100%), the differences were slightly noticeable when you have the video paused (madVR was slightly better to my eyes - whether you would notice these when the video was running without both instances side by side is a whole separate matter). See screenshots here:
http://img828.images...760/snap025.jpg
http://img19.imagesh...41/snap026d.jpg
http://img36.imagesh...43/snap027x.jpg
http://img197.images...086/snap028.jpg

With the SD content, I was able to fit both Zoom windows on the screen side by side (Snap025 and Snap026 - in both images, madVR is on the left, EVR is on the right). With the HD content I had to take the screenshots one at a time (Snap027 and Snap028 - I've gotten myself a little confused with these two shots, but I believe 027 is EVR and 028 is madVR). The difference is subtle as I say, and I needed to pause the video to see it. madshi has posted some other comparison screenshots in his thread here:
http://forum.doom9.o...ad.php?t=146228 (second post)

Take a look at those, and again you will see there is a slight difference, but keep in mind that a renderer cannot take a low quality source and somehow magically make it perfect visual quality - so unless the renderer is badly coded, small differences are what is to be expected.

Note that these shots were taken on a PC monitor - the quality difference may be more pronounced on a HD (Plasma, LCD) TV - that is something I wasn't able to test.

You say madVR doesn't have subtitle support - I thought all subtitle rendering was done by a separate filter anyway (e.g. VSFilter, ffdshow, etc) - what renderers take subtitles directly??


I listed that one because madshi himself lists it as a downside in his intro to madVR here (first post):
http://forum.doom9.o...ad.php?t=146228

known problems / limitations:

- no built-in subtitle support yet (but DirectVobSub/VSFilter/FFDShow can be used)
- DVD playback with navigation/menu currently only works in XP, but not in newer OSs
- hardware accelerated video decoding (DXVA) is currently not supported
- hardware accelerated deinterlacing (DXVA) is currently not supported


I was of the same mind as you until I read that bit - I thought that you would have to use the subtitle filter anyway. Having thought about it since I read it, my guess is that:
1. Built-in to the renderer means that you need no separate filter to use subtitles.
2. Built-in means that the quality of the subtitles is as high as possible.

I know of no renderer currently that doesn't require ffdshow or vobsub to display subtitles however.

Along the same kind of thinking, you say madVR only takes raw video - do other renderers take compressed video as input?? Again, I thought the video codec handled all that and the renderers always required 'raw' video...?


The renderer is typically the last item in the video chain - which means it takes whatever the decoder and filters send to it. So other renderers do take compressed input, yes. It is the decoders that can (if they support it) take RAW input though, not the renderer. I think the difference with madVR is that madVR only takes uncompressed input (which is a bigger performance hit but means maximum quality), whereas other renderers may take uncompressed, but they will also take compressed (meaning less of a performance hit, but less quality as well). madshi's stated aim with madVR is to (quoting from the madVR thread linked above):

- no shortcuts, highest quality has priority over anything else


Basically he is saying that if you want a renderer that takes compressed input, you will have to go elsewhere, because madVR will never do it.

Are there any issues with madVR and DXVA??


Yes, madVR does not currently work with DXVA. Under the known limitations in the madVR thread:

- hardware accelerated video decoding (DXVA) is currently not supported
- hardware accelerated deinterlacing (DXVA) is currently not supported


I didn't list this in my post above because I don't really make use of DXVA, but I know a lot of people do, so it is a point worth listing.

Edited by ehathgepiurhe, 19 March 2011 - 02:54 AM.


#6 magic144

magic144

    Master

  • Members
  • PipPipPipPipPip
  • 549 posts

Posted 19 March 2011 - 03:12 AM

thanks for the hard work in posting all that!!!

I cannot see any differences on my Panny Plasma display between your excellent screen grabs, so I'm not sure madVR is for me!
(perhaps I will see later on my monitor in the office, but since I watch everything on a big HDTV, and I can't see the difference here, it seems unncessary in my case)
...of course, I don't doubt madshi's work and expertise, I use eac3to all the time, it is a fantastic utility!

I'm not sure if we've got confused on the wording for the whole 'renderer taking compressed input' thing
what do you mean by raw vs compressed?
I assumed raw meant decoded (i.e. NOT h.264 or MPEG-2 or the like), but I suspect you are implying that raw means something else - do you mean like RGB32 as compared to another colorspace or something?
I didn't know any renderer (the last item in the chain) took encoded video (e.g. h.264) as input - however I guess with DXVA the decoder is more of a pass-through and gives the compressed stream to the graphics card to handle... is that anything to do with what you meant?? (sorry, this is confusing!!)

I never really understood what a renderer is/does, except to imagine that it is basically the graphics 'driver' interface, i.e. the last layer interacting directly with the graphics card.

Thanks again so much for the detail and all the effort in posting the screen grabs!

ps - I don't use DXVA much either, but that's mostly because I rely on VSFilter to do the most complete/capable job with subtitles of all kinds... ffdshow doesn't handle VobSub subs (DVD-style bitmaps) properly in 720p mkvs... it's a nuisance

#7 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 19 March 2011 - 05:55 AM

I cannot see any differences on my Panny Plasma display between your excellent screen grabs, so I'm not sure madVR is for me!


I honestly think for most people, the difference in image quality between EVR and madVR is so negligible as to be irrelevant :) I should have thrown a screenshot from Haali's in there as well, just to complete the picture!

...of course, I don't doubt madshi's work and expertise


No, neither do I. Having read (literally) every single comment on every single page of the Doom9 madVR thread (now at 303 pages), I can see that some people (and I think I'd include madshi in that), can see minute differences between video renderers, and - minute though they may be - it bothers them enough to strive for the absolute best image they can get. I don't include myself in that group :) Even with those two SD sources paused and sitting next to each other (and looking at the screenshots afterwards), I still wonder if I was imagining seeing the tiny differences between the two images!

I'm not sure if we've got confused on the wording for the whole 'renderer taking compressed input' thing
what do you mean by raw vs compressed?


It is entirely possible that I've confused things, I am good at that! ;)

What I was getting at with regards to raw - and whether this is the 'official' definition of raw I don't know, so I may be using the term in the wrong manner - is basically the video data, which has not had any conversions done to it, or any processing done on it. Compressed to me means that the video data has been converted to another format (YV12 etc - any of the formats listed in the output section of the ffdshow video decoder configuration). Having looked further at the ffdshow video decoder configuration, raw possibly means something else - in the codecs section, you can set ffdshow to handle 'raw video' (disabled by default). That would seem to imply that it isn't the same meaning that I've given to it...

I assumed raw meant decoded (i.e. NOT h.264 or MPEG-2 or the like), but I suspect you are implying that raw means something else - do you mean like RGB32 as compared to another colorspace or something?


See just above, but essentially, yes - that is what I was getting at. If I have used that term wrong, raw wouldn't have meant decoded though I wouldn't have thought, that implies it has had some processing done to it. I'm pretty sure raw means that it hasn't had anything done to it whatsoever.

I didn't know any renderer (the last item in the chain) took encoded video (e.g. h.264) as input - however I guess with DXVA the decoder is more of a pass-through and gives the compressed stream to the graphics card to handle... is that anything to do with what you meant?? (sorry, this is confusing!!)


Digital video is very confusing, and is an absolute mess of competing components. I quite frequently think how it is amazing that we are even able to play video at all with all the rigmarole that is involved in it. Check the thread I linked to below - the encoded video as we understand it (i.e. the file on our hard drive with the extension mkv, avi, mpg etc) doesn't directly go to the renderer, it has to go through some stages before it reaches the renderer so the renderer can make sense of it. All DXVA does is to use the video card to help with the processing, reducing the load on your CPU. It doesn't really modify the steps involved from video file-->splitters, decoders etc-->renderer.

I never really understood what a renderer is/does, except to imagine that it is basically the graphics 'driver' interface, i.e. the last layer interacting directly with the graphics card.


Here is a thread that covers some of the basic terms (including the renderer):
http://forum.doom9.o...ad.php?t=159614

The renderer is the "device" (I use the term loosely, I wasn't sure what else to call it - it isn't actually a physical "device" in the sense of a video card that you can hold in your hands) that actually displays the video data onto your screen basically.

#8 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 19 March 2011 - 01:29 PM

You can apparently now scratch the subtitles thing off the list of "known problems / limitations" of madVR. madshi has just released a new version of the renderer, and with the particular change quoted below, has removed the subtitle line from "known problems / limitations":

* added support for subtitle rendering through ISubRenderCallback


madshi's explanation of this was:

The MPC-HC subtitle renderer now fully works with madVR! However, I had to fix a couple of bugs in MPC-HC to make it work properly. Furthermore I've patched MPC-HC so that it now draws its text messages by using madVR's internal OSD text message system. My bugfixes are already committed to the MPC-HC SVN, so all new SVN builds compiled by other people should also work just fine with madVR v0.44. For your convenience I've uploaded a fixed MPC-HC executable file here:

http://madshi.net/mpc-hc.zip


Edit: One thing I have only just remembered about Haali's and EVR when used with Zoom (problem does not affect other players such as MPC-HC) is that when you pause the video, Zoom skips to the next frame, which is pretty annoying. So add that to the negatives for both renderers. With EVR, it happens on every video file. With Haali's, it only happens on some video files (there is a recent thread about the problem on page 2, and an older thread just for the EVR issue elsewhere on the forum).

Edited by ehathgepiurhe, 19 March 2011 - 01:59 PM.
EVR and Haali negative


#9 magic144

magic144

    Master

  • Members
  • PipPipPipPipPip
  • 549 posts

Posted 19 March 2011 - 02:59 PM

Thanks again ehat

Yeah, from the link you gave it sounds like you were talking about colorspace conversion when you mentioned renderers (some do it, some don't).

Sounds like madshi's subtitle solution is specific to MPC-HC though??

DXVA comes in different flavours from what I've read. Full-capability cards will do the whole decoding process in the GPU - i.e. the decoder hands the driver the encoded bitstream and gets fully-decoded video back. However in the not-too-distant passed, an earlier form of DXVA required some work by the CPU (in the decoding), with only some other stages handled by the GPU.

It's best described here where it talks about the difference between Partial and Complete acceleration in the Nvidia PureVideo DXVA solutions...
http://en.wikipedia....AU_Feature_Sets

Cheers!
m

ps - looked at you screengrabs on my monitor - still can't see a tangible difference!!

#10 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 20 March 2011 - 01:06 AM

Yeah, from the link you gave it sounds like you were talking about colorspace conversion when you mentioned renderers (some do it, some don't).


Heh - I think I even confused myself there, but I think the colourspace thing is what I was referring to.

Sounds like madshi's subtitle solution is specific to MPC-HC though??


Right at the moment, yes. The question has been asked of Blight by someone (not me by the way!) already if Zoom can support this as well. We will see what happens there.

DXVA comes in different flavours from what I've read. Full-capability cards will do the whole decoding process in the GPU - i.e. the decoder hands the driver the encoded bitstream and gets fully-decoded video back. However in the not-too-distant passed, an earlier form of DXVA required some work by the CPU (in the decoding), with only some other stages handled by the GPU.

It's best described here where it talks about the difference between Partial and Complete acceleration in the Nvidia PureVideo DXVA solutions...
http://en.wikipedia....AU_Feature_Sets


Cool, thanks for the link! :)

ps - looked at you screengrabs on my monitor - still can't see a tangible difference!!


:) One more screenshot - can you see any differences here? Slightly differing positions in the video, but that is the goto frame function acting up again. Snap030 is EVR, 031 is madVR. Both are PNG's now, to remove any JPG artifacting.
http://img31.imagesh...68/snap030z.png
http://img163.images...74/snap031v.png

Regards,

ehat

#11 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 20 March 2011 - 12:47 PM

madshi's explanation (page 307 of the madVR thread) of the subtitle change. Question he was replying to:

Thanks, understand now. Any downside with FFDSHOW for decoding+subs if not using MPC-HC?


And his answer:

Yes, ffdshow subs have lower quality and less compatability. The lower quality applies especially for SD content. Because with ffdshow the subs are burned into the video *before* scaling. While with the MPC-HC internal subtitle renderer, the subs are drawn onto the video *after* scaling. Meaning that the subs have a much higher resolution with MPC-HC, when you upscale the video. Of course this doesn't apply to HD content.



#12 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 04 June 2011 - 03:08 AM

Edit: One thing I have only just remembered about Haali's and EVR when used with Zoom (problem does not affect other players such as MPC-HC) is that when you pause the video, Zoom skips to the next frame, which is pretty annoying. So add that to the negatives for both renderers. With EVR, it happens on every video file. With Haali's, it only happens on some video files (there is a recent thread about the problem on page 2, and an older thread just for the EVR issue elsewhere on the forum).


Just clarifying something here. Yes, that behaviour does happen in Zoom, but it isn't a Zoom bug as such. See the update here:
http://forum.inmatri...indpost&p=46210

ehat

#13 Shark

Shark

    Greenhorn

  • Members
  • PipPip
  • 23 posts

Posted 10 June 2011 - 10:12 PM

MadVR by far. The quality difference is slight, but the video play is much smoother compared to Haali/EVR. No sync problems at all.

#14 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 11 June 2011 - 02:20 AM

Yep, it is a very nice piece of work by madshi. It still has a few rough edges for me with Zoom, but it's still in development, so I think it likely those will disappear at some stage.

ehat

#15 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 15 May 2012 - 11:54 AM

Thought I'd just update this topic a little. I know the original part of the thread is 3 years old now, but I occasionally check the forum's online users list just to see what threads are popular - and I quite frequently see this one being viewed (usually by a guest logon, which means someone not logged into an account on the forum, which probably means they came here via a google search for 'best renderer' or similar).

Anyway, some things have changed over the last 3 years since I did the dot point list in post #3 in the thread, so I thought I would compile a new list and just keep it up to date as changes are warranted. So, here we go! :)

VMR (VMR7 & VMR9)

The good:

  • They are very compatible - they will work with quite a range of hardware, both older and newer.
  • If your system is old and/or slow, I would probably recommend these renderers as in my experience, they perform better (less stuttering with video for example) on less capable systems. The reasons for this would be i. The other renderers require better hardware to run smoothly, and ii. The VMR renderers - to my knowledge anyway - don't really perform any (resource intensive) tricks when it comes to displaying the video (scaling, smoothing etc). Though this may mean that video quality is slightly worse (whether you actually notice the difference is another matter).
  • I would also recommend these renderers if you are trying to troubleshoot a video playback problem on your system - so if you aren't sure if the problem is with the renderer you are using, switch to one of the VMR's to test with.

The bad:

  • Nothing really - except they are pretty basic, with not much in the way of more advanced features. This quote from post #3 above still applies: "The old VMR7/VMR9 renderers - They work, but that's about all that can be said for them.". I'm not saying these are bad renderers - they aren't (they work, and working is good!). I'm just saying that if your system is relatively new, there are better alternatives out there.
  • VMR9 Renderless - it is strongly suggested you do not use it. I've noticed a few problems with it on my system, bLight says it is 'a mess' and to top it all off, the frame advance fix in Zoom v9.0 does not work for Renderless (it works for Windowed and Windowless - the fix is basically to stop Zoom from jumping to the next frame in a video when you pause it). Also, triggering a UAC prompt while using VMR9 Renderless will crash Zoom Player.
  • VMR9's are susceptible to washed out colours: http://forum.inmatri...?showtopic=5661

My system is relatively new - and I suspect that this will be so for most people reading this topic - so for me, that leaves the race between 2: madVR and EVR. In my post #3 above, I listed 3 renderers here - EVR, madVR and Haali's. I can no longer recommend Haali's for the reasons detailed below. Keep in mind that if you currently use Haali's and have no issues with it, the information I have listed below is no reason to change your renderer. Though it does not work well for me, if it is working well for you there is no reason to change it. The same would apply if you don't currently use Haali's but were trying to find a renderer that worked for you - try it. If it doesn't work well for you, you haven't lost anything except a small amount of your time.

EVR

The good:

  • Video quality is pretty good. Keep in mind however that the single biggest factor in video quality in a well coded modern media player is down to the clip you are playing - no renderer (or set of filters) will make a 320x240 clip look glorious in fullscreen 1920x1200 for example! What I am trying to say is that a renderer will have an effect on video quality but it's not magic and can't do the impossible - if you have a video clip that has been encoded at a low resolution or very lossy compression, there is nothing you can do to overcome that and you will need to find a better quality version of the clip.
  • Hardware requirements are less than that of madVR, so if your system is not high end (but not really old and slow either), you might want to try this one first.
  • On Windows Vista and Seven, EVR comes built-in to the operating system - meaning no extra download (both madVR and Haali's are separate downloads, though both are offered by Install Center).
  • Very stable in day to day use. I can't say that I have seen any reports of EVR crashing either the player or a system.
  • If you have a video playing, then have a UAC prompt appear, the video will not freeze (by freeze I mean that the audio continues, but the picture gets stuck - this is a problem with some renderers on systems with UAC enabled, which is the default for Vista and Seven).
  • Supports hardware acceleration - DXVA, CUVID, QuickSync.

The bad:

  • If you use Windows XP as opposed to Vista or Seven, EVR is only available with a certain .NET installation (I believe you will need at least v3.5 SP1), which you will need to install separately.
  • I don't believe that this is being actively developed, though I may be wrong about this (if a renderer has a bug, unless it is being actively developed it will not be fixed, so this can be an important factor in your choice of a renderer). Because EVR comes with the operating system essentially, it is hard to tell if Microsoft are making any changes to it - which is why I can't be sure if it is being actively developed or not (I suspect not though).
  • If you are using a version of Zoom Player pre v8.70 Beta, if you use EVR and pause Zoom Player, after a second or two, Zoom will advance to the next frame in the video you are playing. This sounds minor - but is actually pretty annoying.

madVR

The good:

  • Generally regarded as giving the best picture quality - keep in mind that the differences between madVR and other renderers (EVR in particular) may not be apparent with all video files. Some people notice a difference, others don't see any difference, but my experience is that the differences are more noticeable on SD clips (rather than HD clips).
  • Recommended by bLight (Zoom Player lead developer) as the renderer of choice for Zoom Player. As such, it is now integrated with Install Center to make it easier for people to access.
  • Being actively developed (though madshi does have a day job, and occasionally takes a break from this free renderer to do commercial work which he gets paid for). Also being actively supported by madshi in the madVR thread over on Doom9 (with the same caveat - he does take the occasional break to do other things so you won't see him on the forums every single day).
  • Has 'exclusive mode', which helps improve video playing quality in some cases - especially designed to remove tearing.
  • Generally pretty stable in day to day use, though see the very last "bad" note below regarding this.
  • Has a built in set of decoders (based on ffmpeg I think) for certain formats. Unusual for a renderer to have these built-in, but it means that if you use them, you won't need an external decoder for these formats (though I think the internal decoders have limitations such as not being able to be used with hardware acceleration - or something like that, I can't find the reference in the madVR thread now).
  • Doesn't freeze when a UAC prompt is triggered, at least in windowed mode (not tested in exclusive mode, as I can't work out how to trigger a UAC prompt when I can't access the Windows desktop).
  • Allows tuning of the scaling algorithms to your personal taste. Trade off video quality for performance for example.
  • Can automatically set the display refresh rate based on content (i.e. to match the display refresh rate with the FPS of the video you are playing) - this allows smooth playback if your display devices supports the correct refresh rate.
  • Also features automatic de-interlacing, though this is not 100% fool-proof due to how some clips are encoded (if you want you can disable this and just force de-interlacing on with a hotkey on a case by case basis).
  • Allows use of a custom YCMS calibration file for further fine tuning video quality.
  • Gives detailed live statistics (Ctrl+J).
  • Supports hardware acceleration - DXVA, CUVID, QuickSync (v0.85.0 and later required for DXVA2 Native support, otherwise DXVA2 Copy-Back is the only option for DXVA).

The bad:

  • Hardware requirements are higher than for any other renderer as madVR goes for video quality above all else. Requires Windows XP or above, a graphics card with full D3D9 / PS3.0 hardware support (note the bit I have bolded, software support does not count) and at least 128MB of dedicated graphics card memory.
  • Exclusive mode makes madVR function as if it is a game - this means that when in exclusive mode, it is affected by your video driver settings. So if you force anti-aliasing in your video card settings, madVR will be affected. That means the renderer ties into the system a bit, and some people might find that limiting (they might have a setting that works well for their games but does not work well with madVR, and this would mean they would have to constantly change their settings or make a choice as to which way they go).
  • Has a lot of cryptically named options to set if you go into the configuration. This won't be necessary if the installation defaults work for you, but if you want to tweak your video playback, this means you will have to i. Have a lot of time and patience (to try different combinations of settings), and ii. Will have to have a fairly in-depth knowledge of video playback if you want to do anything more than set options at random (there is no helpfile explaining each option - if you can't work out what it does by the name, or by a search of the madVR thread over on Doom9, you are out of luck).
  • As it is more resource intensive, it is more likely to show up any problems in your system - you do see reports of madVR crashing the video player from time to time for example. More stress on a system equals a bigger chance of showing up any weaknesses in it.
  • More "hit and miss" (i.e. it will either work well on your system, or it won't) than any of the other renderers. You do see reports of people who have nothing but trouble with madVR (such as myself for example), and reports from people who have no issues with madVR at all - you never really see anything in-between. This is likely related to the hardware requirements of the renderer, and the fact that it is more dependent on your overall system configuration than any other renderer. In simple terms, unlike with the other renderers, with madVR, you won't know if it is going to work well or not on your system until you actually try it.
  • If you are using a version of madVR pre v0.86.3, if you have the Zoom OSD enabled, Zoom is in fullscreen mode and the automatic FSE mode option in madVR is enabled, when you pause a video, Zoom will move the video to the previous frame after a second or two. Basically the same issue as with EVR, where it Zoom moves to the next frame after you pause a video (except with EVR it is the next frame in the video, and with madVR it is the previous frame).

Haali's

The good:

  • Good colour reproduction (Haali's used to be my primary renderer, and this was the thing that attracted me to it).

The bad:

  • Video freezes when a UAC prompt is triggered.
  • Development has ceased (Haali now works for the company that produces CoreAVC). This means that any bugs will not be fixed (see below).
  • Features a built-in (with no option to disable it) resizing algorithm (if the renderer detects that the media player window will be within a certain distance of the edge of the monitor, it resizes the video player window to half size). This is by design and isn't a bug. Some people might see this as a positive (Haali obviously did, he was never willing to change it when the renderer was under active development), but I suspect that more people will find this very irritating than what liked it, so I have listed it as a negative.
  • I have encountered quite a few bugs on my system that affect playback enough to be quite noticeable when Haali's is used with Zoom (including what I think is the single weirdest bug I have ever encountered in any software) - making it a frustrating combination to use. This is the primary reason why I no longer recommend Haali's (though the resizing behaviour comes a close second, that irritated the life out of me). To be fair, your mileage may vary however - each system is different.
  • Also afflicted by the same 'Zoom will advance to the next frame of the video when you pause playing' bug as EVR and madVR.

Personally, I now use madVR as my main renderer, only swapping to the other renderers for bug-testing and troubleshooting purposes. EVR is good - but I do notice a slight increase in the image quality of some clips when using madVR. Putting that aside, EVR is the least problematic renderer for my system overall, as it doesn't push the hardware envelope as much as madVR.

 

Still, I prefer madVR - when the current version is working well with my system that is, as it is at the moment - so that is what I use currently. I personally do not have fullscreen exclusive mode enabled in madVR, and would advise others to have it disabled as well, but it's a personal choice (it can improve playback in some cases, but it has some side-effects). The reason why I have it disabled is that I see too many problems with it:

  • The frame jump mentioned above with versions prior to 0.86.3
  • The quick flicker of a frame of the previous video when you move to the next video in the playlist in some circumstances
  • The slight slowdown in entering and exiting fullscreen mode
  • If you open a dialog (e.g. the "Open" dialog by hitting "O") while in fullscreen with FSE enabled, you will not be able to interact with it as the mouse cursor is not available

None of those occur with fullscreen exclusive disabled. Anyway, your mileage with madVR - as the old saying goes - will vary, I guarantee it. How well madVR works is very dependent on your system. It may work fantastically on your system, it may work horribly on your system - or it may be somewhere in-between (some good things, some bad things).

 

ehat


Edited by ehathgepiurhe, 26 April 2014 - 01:51 AM.
Updated VMR9 Renderless, EVR, madVR


#16 wdekler

wdekler

    Adept

  • Members
  • PipPipPip
  • 142 posts

Posted 16 May 2012 - 10:11 AM

Hi Ehat.

MadVR has some other notable features as well:

- tuning of the scaling algorithms to your personal taste.
- automatically set display refresh rate based on content (the only way to achieve this in ZP?)
- Use of a custom ycms calibration file for further fine tuning video quality.
- detailed live statistics

Subtitles should be rendered by a filter and I'm not shure why EVR should be considered better in this regard? The same goes for colour controls imho.

By using the LAV filters you can add some DXVA support by using the copyback function (not as fast but it can be helpful if you can't use CUDA or Quicksync).

The only things missing for me are DVD support (although a hack exists) and full 3D support (SBS works).

#17 ehathgepiurhe

ehathgepiurhe

    Lead QA

  • Members
  • PipPipPipPipPip
  • 6710 posts

Posted 16 May 2012 - 11:22 AM

Hi wdekler,

MadVR has some other notable features as well:

- tuning of the scaling algorithms to your personal taste.
- automatically set display refresh rate based on content (the only way to achieve this in ZP?)
- Use of a custom ycms calibration file for further fine tuning video quality.
- detailed live statistics


Yes, good points, I will add those to the list.


Subtitles should be rendered by a filter and I'm not shure why EVR should be considered better in this regard?


Yes, that is fair enough - I've removed the subs point from EVR and from madVR as well.


The same goes for colour controls imho.


In this case, madVR does not allow the player to change the colour controls (while EVR does) - which will be a big negative for some people. I will clarify that in the list that I was referring to it blocking the player.


By using the LAV filters you can add some DXVA support by using the copyback function (not as fast but it can be helpful if you can't use CUDA or Quicksync).


I was aware that LAV has hardware acceleration, but I use CUVID in LAV Video myself. madshi himself says in the features list on Doom9 that DXVA does not work, that item I put in the list is actually a direct quote - so it does in fact work if you force it with LAV?


The only things missing for me are DVD support (although a hack exists) and full 3D support (SBS works).


I'm not a 3D fan myself, but I know there are some around - full 3D support will be a long time coming from reading between the lines in the madVR and LAV threads on Doom9 unfortunately. DVD working 100% would be nice - but I think it is mitigated some. I suspect most power users of Zoom no longer use DVD disks (instead their files are ripped to the HDD and aren't affected by this limitation), and most non-power users would not even know what a renderer was anyway or leave it as the default (EVR). Still, it would be nice to have it working, and madshi does know about it, so I suspect that once he takes a proper look at it, it will get fixed.

I also added another negative for Haali's - it freezes when a UAC prompt is triggered.

ehat

Edit: I missed this bit originally:

(the only way to achieve this in ZP?)


Zoom does have a basic display refresh rate changing mechanic (in Advanced Options-->Interface-->Display), but it is only for Fullscreen mode only, and does not try to match the refresh rate of the display to that of the clip in any way (you enter a value manually). So this is mostly - but technically not 100% - correct. That's assuming I have understood you correctly (if I haven't, let me know).

I also changed the formatting of the list - hopefully it makes it more readable :)

Edited by ehathgepiurhe, 16 May 2012 - 11:38 AM.
Missed a bit!


#18 thany

thany

    Adept

  • Members
  • PipPipPip
  • 50 posts

Posted 20 May 2012 - 01:44 AM

Why isn't there ONE renderer that just works everywhere. Who cares what the setting is, just let ZP find out which one is the best for any system and be done with it. There are only two players in my knowledge that let the user decide on the renderer (really, "what?" I hear people ask). One of them is MPC, which is dead, and the other is ZP. EVERY other player *just works*.

So why does this setting exist in the first place?

#19 boogafreak

boogafreak

    BoogAdmin

  • Members
  • PipPipPipPipPip
  • 3159 posts

Posted 20 May 2012 - 11:11 AM

Thany, you can use Smart Play...

#20 wdekler

wdekler

    Adept

  • Members
  • PipPipPip
  • 142 posts

Posted 22 May 2012 - 09:44 AM

Hi Ehat,


with the refresh change option of MadVR I specifically meant the match the clip frame rate option. This is the only way to guarantee smooth playback (if your device is capable of the needed refreshrates).

Native DXVA support isn't possible with MadVR. However the LAV decoder offers some DXVA support by using the DXVA2 copyback feature which can be used with MadVR. This offers some DXVA benefits but on AMD cards (older than the 7000 series) the performance isn't very good. Hopefully Madshi will implement his in a later version but it isn't on top of his todo lists. And rightly so because other options like CUVID and Quicksync are working fine.

There are some options of getting madvr to work with DVD playback but none of them worked for me, see: http://forum.doom9.o...ad.php?t=159492 So some more testing and hacking is in order or patiently await Madshi's updates.