madVR - high quality video renderer (GPU assisted)

[madshi]

http://madshi.net/madVR.zip

madVR v0.92.17

* modified/simplified HDR tone mapping settings page
* small HDR tone mapping saturation improvement
* OSD now also shows the measured luminance of the current frame (in addition to the average)
* fixed: render & present queues didn't always fill in Windows 10 build 1803
* fixed: using XySubFilter sometimes resulted in black screen / freeze
* fixed: using HDR "processing" resulted in dark and red-ish image
* fixed: using BT.601/709 gamma curve with HDR tone mapping produced gray-ish image
* fixed: settings dialog sometimes crashed on display mode / custom mode tab
madVR v0.92.15

* HDR: improved overall tone mapping quality
* HDR: added "color tweaks for fire & explosions" option
* HDR: "restore details in compressed highlights" renamed to "highlight recovery"
* HDR: improved "highlight recovery" algo, now uses/requires DirectCompute
* HDR: added trade quality option "compromise on tone & gamut mapping accuracy"
* HDR: maxCLL is now used (if valid)
* HDR: added "hdrVideoPeak" profile variable
* HDR: added (limited) support for HDR OSD bitmaps
* added "report BT.2020 to display" calibration option
* added true GPU mode info (color format, bitdepth & dynamic range) to OSD (Nvidia only)
* fixed: low latency mode could result in judder/stuttering
* fixed: OSD API sometimes drew stuff in the wrong position
* fixed: madHcNet32/64.dll produced DCI-P3 3DLUTs with incorrect header
* added undocumented "ShowHdrMode" empty file/folder option
madVR v0.92.13

* added 2 new RCA quality levels, with NGU fusion support
* if "activate RCA only if it comes for free" is active, NGU quality level isn't modified, anymore
* improved "preserve hue" tone mapping quality
* added "dynamic" mode for "luminance vs saturation reduction" option
* added "dumb" tone mapping algo, optionally with color correction
* added support for Arve custom tone mapping curves
* added "hdrOutput" information field
madVR v0.92.5

* added new algorithm "reduce compression artifacts"
* added new algorithm "reduce random noise"
* added file name tag and keyboard shortcut support for new algorithms
* switched to igv's AdaptiveSharpen variant
* custom mode optimization is now available for modes not created with madVR
* fixed: mode optimization didn't work for Nvidia (introduced in v0.92.4)
* fixed: ProgDVB: DXVA deinterlacing didn't activate after channel switch
* fixed: potential freeze when freeing madVR instance
* fixed: playback trouble after switching video files (introduced in v0.92)
* fixed: screenshot memory leak
madVR v0.92.0

* added new "display modes" -> "custom modes" settings tab
* added support for native D3D11 DXVA hardware decoding (needs nightly LAV)
* added support for outputting 10bit in fullscreen windowed mode (win10)
* added optimized "let madVR decide" HDR configuration option
* added support for AMD's private HDR switching API
* added workaround for make Nvidia's private HDR switching API work better
* added full-size EDID block reading (256 bytes instead of just 128)
* added extended EDID parsing
* improved frame drop/repeat estimates for xx/1.001 hz modes
* fixed: deinterlacing of P010 software decoded videos was broken

download links:

You can download old madVR versions here (http://www.videohelp.com/tools/madVR/old-versions#download). The "madTestPatternSource" filter (madVR test patterns) is available here (http://madshi.net/madTestPatternSource.zip).

The XySubFilter subtitle renderer, using the "new subtitle interface", is available here (http://forum.doom9.org/showthread.php?t=168282).

If you want to test whether your display supports RGB in 4:2:0, 4:2:2 or 4:4:4, you can use this (http://madshi.net/madVR/ChromaRes.png) test image. Make sure you display it with 1:1 pixel mapping, otherwise it won't work.

3rd party tools (for HDR):

1) "madMeasureHDR Optimizer" created by Anna & Flo:
https://www.avsforum.com/forum/26-home-theater-computers/3040072-madvr-tool-madmeasurehdr-optimizer-measurements-dynamic-clipping-target-nits.html

2) "Simple Analyzer for madMeasureHDR" created by pandm1967 (use download link in pandm1967's signature):
https://www.avsforum.com/forum/26-home-theater-computers/3040072-madvr-tool-madmeasurehdr-optimizer-measurements-dynamic-clipping-target-nits-11.html#post57433788

3) "Simple AutoMeasure Tools for UHD clones" created by pandm1967 (use download link in pandm1967's signature):
https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-163.html#post57434744

features:

- high quality chroma upsampling
- high quality scaling (bicubic, mitchell, lanczos, spline etc)
- high quality YCbCr -> RGB conversion
- gamut & gamma correction for display calibration
- full 16bit processing queue
- final 16bit processing result is dithered down to RGB output bitdepth
- bypasses graphics card's video (damage) algorithms
- all work is done via GPU shaders (except madVR's IVTC atm)
- no shortcuts, highest quality has priority over anything else

requirements:

- graphics card with full D3D9 / PS3.0 hardware support
- at least 128MB of dedicated graphics card memory
- Windows XP or newer

known problems / limitations:

None known.

bug tracker:

http://madVR.bugs.madshi.net

firewall complaints:

madVR tries to automatically find other PCs in your local network which are also running madVR. If any such PCs are found, you can remotely switch audio and subtitle tracks, jump to specific chapters, etc etc. For this network functionality to work, madVR tries to access the local network, obviously. So if your firewall complains, you know why. If you don't ever plan to use madVR's network functionality, you can safely tell your firewall to block any and all madVR network accesses. Please rest assured, though, that madVR does not upload your private data to a server or anything of that sort. So allowing madVR to access the LAN should not result in any privacy or security problems.

custom mode tutorial:

http://madvr.com/crt/CustomResTutorial.html

-----
MODERATOR Note: This thread has had a tendency to generate long off-topic discussions. madshi has stated that the thread is for madVR support/development and not for related general discussion. Please confine this thread to direct madVR-related support/development issues. If in doubt, start a new thread and put a simple link to it if needed. If you put madVR in the thread title, people will find it. The moderating policy being enforced, including deletion of off-topic posts and material, has been discussed with and approved by madshi. Thank you for your cooperation in keeping the thread manageable for madshi and his users.
-----

[madshi]

FAQ:

A) Which output format (RGB vs YCbCr, 0-255 vs 16-235) should I activate in my GPU control panel?

Windows internally always "thinks" in RGB 0-255. Windows considers black to be 0 and white to be 255. That applies to the desktop, applications, games and videos. Windows itself never really thinks in terms of YCbCr or 16-235. Windows does know that videos might be YCbCr or 16-235, but still, all rendering is always done at RGB 0-255. (The exception proves the rule.)

So if you switch your GPU control panel to RGB 0-255, the GPU receives RGB 0-255 from Windows, and sends RGB 0-255 to the TV. Consequently, the GPU doesn't have to do any colorspace (RGB -> YCbCr) or range (0-255 -> 16-235) conversions. This is the best setup, because the GPU won't damage our precious pixels.

If you switch your GPU control panel to RGB 16-235, the GPU receives RGB 0-255 from Windows, but you ask the GPU to send 16-235 to the TV. Consequently, the GPU has to stretch the pixel data behind Windows' back in such a way that a black pixel is no longer 0, but now 16. And a white pixel is no longer 255, but now 235. So the pixel data is condensed from 0-255 to 16-235, and all the values between 0-15 and 236-255 are basically unused. Some GPU drivers might do this in high bitdepth with dithering, which may produce acceptable results. But some GPU drivers definitely do this in 8bit without any dithering which will introduce lots of nasty banding artifacts into the image. As a result I cannot recommend this configuration.

If you switch your GPU control panel to YCbCr, the GPU receives RGB from Windows, but you ask the GPU to send YCbCr to the TV. Consequently, the GPU has to convert the RGB pixels behind Windows' back to YCbCr. Some GPU drivers might do this in high bitdepth with dithering, which may produce acceptable results. But some GPU drivers definitely do this in 8bit without any dithering which will introduce lots of nasty banding artifacts into the image. Furthermore, there are various different RGB <-> YCbCr matrixes available. E.g. there's one each for BT.601, BT.709 and BT.2020. Now which of these will the GPU use for the conversion? And which will the TV use to convert back to RGB? If the GPU and the TV use different matrixes, color errors will be introduced. As a result I cannot recommend this configuration.

Summed up: In order to get the best possible image quality, I strongly recommend to set your GPU control panel to RGB Full (0-255).

There's one problem with this approach: If your TV doesn't have an option to switch between 0-255 and 16-235, it may always expect black to be 16 (TVs usually default to 16-235 while computer monitors usually default to 0-255). But we've just told the GPU to output black at 0! That can't work, can it? Actually, it can, surprisingly - but only for video content. You can tell madVR to render to 16-235 instead of 0-255. This way madVR will make sure that black pixels get a pixel value of 16, but the GPU doesn't know about it, so the GPU can't screw image quality up for us. So if your TV absolutely requires to receive black as 16, then still set your GPU control panel to RGB 0-255 and set madVR to 16-235. If your GPU supports 0-255, then set everything (GPU control panel, TV and madVR) to 0-255.

Unfortunately, if you want application and games to have correct black & white levels, too, all the above advice might not work out for you. If your TV doesn't support RGB 0-255, then somebody somewhere has to convert applications and games from 0-255 to 16-235, so your TV displays black & white correctly. madVR can only do this for videos, but madVR can't magically convert applications and games for you. So in this situation you may have no other choice than to set your GPU control panel to RGB 16-235 or to YCbCr. But please be aware of that you might get lower image quality this way, because the GPU will have to convert the pixels behind the back of both Windows and madVR, and GPU drivers often do this in inferior quality.

B) FreeSync / G-SYNC

Games create a virtual world in which the player moves around, and for best playing experience, we want to achieve a very high frame rate and lowest possible latency, without any tearing. As a result with FreeSync/G-SYNC the game simply renders as fast as it can and then throws each rendered frame to the display immediately. This results in very smooth motion, low latency and a very good playability.

Video rendering has completely different requirements. Video was recorded at a very specific frame interval, e.g. 23.976 frames per second. When doing video playback, unlike games, we don't actually render a virtual 3D world. Instead we just send the recorded video frames to the display. Because we cannot actually re-render the video frames in a different 3D world view position, it doesn't make sense to send frames to the display as fast as we can render. The movie would play like fast forward, if we did that! For perfect motion smoothness, we want the display to show each video frame for *EXACTLY* the right amount of time, which is usually 1000 / 24.000 * 1.001 = 41.708333333333333333333333333333 milliseconds.

FreeSync/G-SYNC would help with video rendering only if they had an API which allowed madVR to specify which video frame should be displayed for how long. But this is not what FreeSync/G-SYNC were made for, so such an API probably doesn't exist (I'm not 100% sure about that, though). Video renderers do not want a rendered frame to be displayed immediately. Instead they want the frames to be displayed at a specific point in time in the future, which is the opposite of what FreeSync/G-SYNC were made for.

If you believe that using FreeSync/G-SYNC would be beneficial for video playback, you might be able to convince me to implement support for that by fulfilling the following 2 requirements:

1) Show me an API which allows me to define at which time in the future a specific video frame gets displayed, and for how long exactly.
2) Donate a FreeSync/G-SYNC monitor to me, so that I can actually test a possible implementation. Developing blindly without test hardware doesn't make sense.

[madshi]

How to configure profile rules:

The madVR settings profiling logic is very flexible, but also requires a bit of scripting for best effect. Script language is pretty easy. Basically scripting is expected to be a string of "if", "else if" and "else" statements. Every "if" (or "else if") statement contains of one or more value comparisons and selects one profile to be activated. Each value comparison must be placed in brackets. By using the logical operations "and" or "or" you can check multiple values to create more complex decisions.

Let's look at an example. The following script selects one of 4 profiles, depending on the source dimensions and the frame rate after deinterlacing. I think the script is pretty much self explaining:
if (srcWidth <= 1050) and (srcHeight <= 768) and (deintFps < 31) "SD 24fps"
else if (srcWidth <= 1050) and (srcHeight <= 768) "SD 60fps"
else if (deintFps < 31) "HD 24fps"
else "HD 60fps"

Supported keywords and operators:
if/else statements: "if", "else if", "elseif", "elsif", "else"
logical operators: "and", "or", "&&", "||"
equal check: "==", "="
unequal check: "!=", "<>", "#"
bigger/smaller check: "<", ">", "<=", ">="
boolean "not" operator: "not", "!"

Supported numerical values:
srcWidth, srcHeight src width/height (cropping according to settings)
croppedSrcWidth, croppedSrcHeight cropped src width/height
uncroppedSrcWidth, uncroppedSrcHeight uncropped src width/height
AR, uncroppedAR, encodedAR cropped AR (aspect ratio), uncropped AR, encoded AR,
targetWidth, targetHeight width/height after scaling (cropping according to settings)
croppedTargetWidth, croppedTargetHeight width/height after scaling cropped source
uncroppedTargetWidth, uncroppedTargetHeight width/height after scaling uncropped source
scalingFactor.x/y overall scaling factor
fps, deintFps, bitDepth source frame rate, framerate after deinterlacing, bitdepth
displayMode.x/y, refreshRate display mode information
runtime movie runtime (in minutes)
hdrVideoPeak video peak luminance (in Nits) -> maxCLL (if valid) or SMPTE 2086

Supported boolean values:
4:2:0, 4:2:2, 4:4:4, RGB which pixel format does the source have?
HDR is the video HDR?
srcInterlaced is the source interlaced?
filmMode is film mode (IVTC) active?
MPEG2, VC-1, h264 which codec is the source encoded in?
exclusive, overlay, windowed rendering mode
fullscreen is playback borderless fullscreen (can be windowed or exclusive)
AMD, nVidia, Intel which GPU manufacturer are we rendering on?
smoothMotion is smooth motion FRC active?
variableAR does this video have variable ARs?
hdr is the video HDR?
battery is this a laptop running on battery?

Supported string values:
mediaPlayer media player exe file name
filePath, fileName, fileExt e.g. "c:\movie.mkv", "movie.mkv", "mkv", wildcards supported
display name of the active display device

One more example to show how to use numerical, boolean and string values:
if ((not 4:2:0) or (AR = 16:9)) and (fileName = "*horribleSubs*.mkv") "Weird profile" else "Normal profile"

[madshi]

technical discussion:

I've seen many comments about HDMI 1.3 DeepColor being useless, about 8bit being enough (since even Blu-Ray is only 8bit to start with), about dithering not being worth the effort etc. Is all of that true?

It depends. If a source device (e.g. a Blu-Ray player) decodes the YCbCr source data and then passes it to the TV/projector without any further processing, HDMI 1.3 DeepColor is mostly useless. Not totally, though, because the Blu-Ray data is YCbCr 4:2:0 which HDMI cannot transport (not even HDMI 1.4). We can transport YCbCr 4:2:2 or 4:4:4 via HDMI, so the source device has to upsample the chroma information before it can send the data via HDMI. It can either upsample it in only one direction (then we get 4:2:2) or into both directions (then we get 4:4:4). Now a really good chroma upsampling algorithm outputs a higher bitdepth than what you feed it. So the 8bit source suddenly becomes more than 8bit. Do you still think passing YCbCr in 8bit is good enough? Fortunately even HDMI 1.0 supports sending YCbCr in up to 12bit, as long as you use 4:2:2 and not 4:4:4. So no problem.

But here comes the big problem: Most good video processsing algorithms produce a higher bitdepth than you feed them. So if you actually change the luma (brightness) information or if you even convert the YCbCr data to RGB, the original 8bit YCbCr 4:2:0 mutates into a higher bitdepth data stream. Of course we can still transport that via HDMI 1.0-1.2, but we will have to dumb it down to the max, HDMI 1.0-1.2 supports.

For us HTPC users it's even worse: The graphics cards do not offer any way for us developers to output untouched YCbCr data. Instead we have to use RGB. Ok, e.g. in ATI's control panel with some graphics cards and driver versions you can activate YCbCr output, *but* it's rather obvious that internally the data is converted to RGB first and then later back to YCbCr, which is a usually not a good idea if you care about max image quality. So the only true choice for us HTPC users is to go RGB. But converting YCbCr to RGB increases bitdepth. Not only from 8bit to maybe 9bit or 10bit. Actually YCbCr -> RGB conversion gives us floating point data! And not even HDMI 1.4 can transport that. So we have to convert the data down to some integer bitdepth, e.g. 16bit or 10bit or 8bit. The problem is that doing that means that our precious video data is violated in some way. It loses precision. And that is where dithering comes to rescue. Dithering allows to "simulate" a higher bitdepth than we really have. Using dithering means that we can go down to even 8bit without losing too much precision. However, dithering is not magic, it works by adding noise to the source. So the preserved precision comes at the cost of increased noise. Fortunately thanks to film grain we're not too sensitive to fine image noise. Furthermore the amount of noise added by dithering is so low that the noise itself is not really visible. But the added precision *is* visible, at least in specific test patterns (see image comparisons above).

So does dithering help in real life situations? Does it help with normal movie watching?

Well, that is a good question. I can say for sure that in most movies in most scenes dithering will not make any visible difference. However, I believe that in some scenes in some movies there will be a noticeable difference. Test patterns may exaggerate, but they rarely lie. Furthermore, preserving the maximum possible precision of the original source data is for sure a good thing, so there's not really any good reason to not use dithering.

So what purpose/benefit does HDMI DeepColor have? It will allow us to lower (or even totally eliminate) the amount of dithering noise added without losing any precision. So it's a good thing. But the benefit of DeepColor over using 8bit RGB output with proper dithering will be rather small.

[TheFluff]

Looks like it uses PC levels without any option to expand TV->PC. Other than that, seems to work fine in my extremely brief test. Works fine as a custom renderer in zoomplayer. Quite slow in changing window size and going between fullscreen/windowed mode, but I guess that's to be expected.

(nice job, by the way)

[madshi]

Looks like it uses PC levels without any option to expand TV->PC. Other than that, seems to work fine in my extremely brief test. Works fine as a custom renderer in zoomplayer.
You're too quick!! :D I'm still working on the description and documentation (see "reserved" posts).

YCbCr -> RGB conversion is done through a 96MB 3dlut file. The 3dlut file shipping with madVR is using PC levels. You can however create your own file with any custom setting you want. Please check out this thread to learn more about this topic:

http://forum.doom9.org/showthread.php?t=139389

[leeperry]

these test patterns look somewhat familiar :)

awesome project btw! do you plan on adding jitter correction(a la HR) and means to synchronise to the VSYNC fliptime ?

this is the real enemy : http://software.intel.com/en-us/articles/video-frame-display-synchronization

96MB seems quite a lot, why not only 5-6 frames?

hopefully when it'll be mature, James won't mind adding support for it in Reclock :)

EDIT: oh cool it reads LUT's from yesgrey's software :eek:

[Rectal Prolapse]

madshi, have you tested this with neuron2's VC1/AVC CUDA decoder, or coreavc's CUDA? That can get you back some h/w acceleration. :)

[madshi]

do you plan on adding jitter correction(a la HR) and means to synchronise to the VSYNC fliptime ?
I'm not sure yet which exact method I'll use to get motion display smooth, but I do plan to make sure that at least with a 1:1 match between source frame and display refresh rate motion display will be smooth. Such a feature is not implemented yet, though. After all, this is just a very first beta release to get some feedback from users with different graphics cards.

96MB seems quite a lot, why not only 5-6 frames?
Those 96MB are spent on the 3dlut file (for YCbCr -> RGB conversion, gamut & gamma correction), not on frame storage!

madshi, have you tested this with neuron2's VC1/AVC CUDA decoder, or coreavc's CUDA? That can get you back some h/w acceleration. :)
I have an ATI card, so I can't test that. However, yesgrey has already tested CUDA + madVR and generally it works, although it seems that with a low range graphics card using both CUDA + madVR at the same time may be too much of a burden for the GPU.

[Atak_Snajpera]

@madshi
Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)

[leeperry]

@madshi
Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)
the biggest problem w/ EVR is the ugly EE it adds, yet it doesn't show on screenshots :confused:
they must be doing it after the RGB32 mixer, behind the scene. Use LSF in ffdshow, play a video in EVR then in HR on a large screen...they don't look quite similar, the picture in EVR is more 3D-like and its EE algorithm interferes w/ LSF, making the picture way oversharpened(VMR9 has the same problem, but less EE)

a D3D renderer that'd keep the PQ untouched(like HR), use yesgrey's LUT and sync to the VSYNC fliptime is one hell of a terrific idea :devil:

but on Vista, Aero forces the VSYNC constantly...which makes HR jerky to hell...hopefully madshi will find a workaround for this, making it XP compatible too :o

[madshi]

Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)
That's a gone one. I've updated the screenshots. You may need to press F5 to reload the images.

In the "Jacques Pibarot" test the MPC-HC YV12 Shader is *almost* as good as madVR. But in the other chroma upsampling test madVR is still in a class of its own.

[Atak_Snajpera]

@leeperry
What does 'EE' stand for?

[madshi]

Edge Enhancement, which often produces ringing (typically white ghost lines next to high contrast edges).

[leeperry]

@leeperry
What does 'EE' stand for?
Edge Enhancement : www.videophile.info/Guide_EE/Page_01.htm

[Mark_A_W]

Thanks Madshi

I would be awesome if you integrated it with Reclock (sync to V-sync or something). Smoothness is the most important to me (and no tearing!).

[DeepBeepMeep]

Many thanks Madshi for this new creation!

However, I am not sure I have understood its added value compared to VMR9/EVR for a typical usage, I mean is there any real benefit to use this renderer if no resize is needed for the playback of a 1080p movie on an 1080p screen using HDMI 1.0?

On a side note I have noticed that when a player that uses the renderer (in my case zoomplayer) is in the background the CPU usage rises to 50% even in pause mode.

[yesgrey]

Here is the link for the new reclock release that already supports madVR, I've requested it to James (reclock's current developer) and he was so nice to add it imediatelly.:)
http://forum.slysoft.com/showthread.php?t=19931

[honai]

I just knew madshi was cooking up something, but I suspected he might be the force behind the mysterious SlyPlayer. ;)

This is really amazing work, madshi, thank you very much! It proves once again that when it comes to obsessing about quality nothing beats German engineering. :) And I'm in total agreement, when we can get the best quality why compromise?

One question: Does madVR actually support 10-bit data paths in GPU drivers?

[jmone]

Is there a list of what apps work with this renderer so far? I'm particulary intereted if anyone has it working with:
- JR Media Center
- Arcsoft TMT V3

Thanks
Nathan

[STaRGaZeR]

The renderer is just amazing. List of things to improve to make it perfect for me:

- Improve windowed - fullscreen change if possible. Now it takes too much time and the image does some weirdness that's ugly to see.
- Improve load time. It's not that slow but if it can be improved... :p
- Support for MPC-HC shaders or similar.
- Output options ala ffdshow (levels, 601vs709, etc.)
- Stats ala MPC-HC

[Mark_A_W]

This renderer raises a dilemma...

Do we use:

- MadVR

or

- MPC HC with EVR Custom with Beliyaal's tweaks for smoothness?

I hope this gets "united" with MPC HC, getting all the tweaks that EVR Custom is getting - and eventually replaces EVR Custom as preferred/tweaked renderer in MPC HC.

[madshi]

I am not sure I have understood its added value compared to VMR9/EVR for a typical usage, I mean is there any real benefit to use this renderer if no resize is needed for the playback of a 1080p movie on an 1080p screen using HDMI 1.0?
Well, even if you don't have to resize, you still get best in class chroma upsampling, a full 16bit processing queue with all its benefits for image quality and best in class YCbCr -> RGB conversion with included gamut & gamma correction. Finally, due to the way madVR works, all the damaging video processing algorithms which graphics card manufacturers like to use, are disabled.

On a side note I have noticed that when a player that uses the renderer (in my case zoomplayer) is in the background the CPU usage rises to 50% even in pause mode.
This does not happen with MPC HC for me. Seems to be a ZoomPlayer specific problem?

One question: Does madVR actually support 10-bit data paths in GPU drivers?
Actual processing is done in 32bit floating point (that's the native processing bitdepth of GPU shaders), but temp buffers used for storing processing results can be either 16bit or 10bit, depending on the madVR settings. Final RGB output bitdepth at this time is always dithered down 8bit, but the down dithering is only done in the very last step. I'm planning to add support for 10bit and 16bit output modes once Windows 7 arrives. The 10bit/16bit switch in the madVR settings only applies to the temp buffers.

Is there a list of what apps work with this renderer so far? I'm particulary intereted if anyone has it working with:
- JR Media Center
- Arcsoft TMT V3
Seemingly: MPC HC (special build), ZoomPlayer and ReClock.

You'll have to ask the JR Media Center and ArcSoft guys about madVR support. Not sure if there's any chance with ArcSoft because they may need to use protected data paths for copy protected material, which madVR doesn't support.

- Improve windowed - fullscreen change if possible. Now it takes too much time and the image does some weirdness that's ugly to see.
Can you describe that weirdness for me? Is there some visible corruption? Or is the image just squeezed for a short time?

- Improve load time. It's not that slow but if it can be improved... :p
I'm not sure if it can be improved much. Reading a 96MB file does take its time.

- Support for MPC-HC shaders or similar.
That will require a combined effort on my side and MPC-HC side, but it should be possible to do. One problem is that I think the best place for some shaders would be in YCbCr space and madVR could offer that to custom shaders, while VMR/EVR can not. So MPC-HC currently does not support YCbCr shaders.

BTW, forgot to mention: Subtitle rendering is currently not supported. That needs to be added, too.

- Output options ala ffdshow (levels, 601vs709, etc.)
- Stats ala MPC-HC
That's already planned.

I hope this gets "united" with MPC HC, getting all the tweaks that EVR Custom is getting - and eventually replaces EVR Custom as preferred/tweaked renderer in MPC HC.
madVR getting united with MPC HC is not in the cards, because I want madVR to be media player independent. You know, although personally I'm using MPC HC for now, some people prefer ZoomPlayer.

But as explained in the first few posts of this thread, I'm planning to work on motion smoothness.

--------------------

Can I get some specific feedback, please? I'm especially interested in playback smoothness? Do you guys get stuttering with madVR? Or is your graphics card fast enough? How smooth or non-smooth is motion display for you currently? Especially if you set display refresh rate to 1:1 match with the source frame rate? Are the Beliyaal special builds a lot smoother for you, or only slightly so? Thanks!

[jmone]

You'll have to ask the JR Media Center and ArcSoft guys about madVR support. Not sure if there's any chance with ArcSoft because they may need to use protected data paths for copy protected material, which madVR doesn't support.

I've asked the JR Media Center guys - will advise of the response.

??? on the Arcsoft stuff....

[madshi]

??? on the Arcsoft stuff....
Well, you can ask the ArcSoft guys, too. Maybe they'll add support for it. The problem I see is that ArcSoft can play Blu-Rays and they have an official license for that. Consequently they are forced to protect the Blu-Ray content from being copied. Which means that they can't just use any renderer. After all, madVR could have a hidden feature (it does not) that secretly stores the Blu-Ray video stream to harddisk!

[Thunderbolt8]

looks great, must test it in the next days.

could you please also add comparison pics to the haali renderer? I guess that its used by many people as their standard renderer (at least for me :D ) thats why I'd like how your renderer compares to it. thanks!

btw. I also like that it displays comparable good quality when downscaling, since I can watch 1080p stuff only on 720p screen here

[wozio]

chroma upsampling comparison:

http://madshi.net/madVR/chroma upscampling comparison 1.png

A picture says more than 1000 words. I don't think I have to comment this, do I? :)


What was input color space when using VMR9. I never seens such horrible VMR9/EVR output. Did you use YV12 or YUY2? If yes then it is very unfair comparision since on ATI NV12 is color space of choice. It produces very good results near that bad as on your screenshots.

I will check at home later today how it is going on my system.

Regards
Piotr

[Hypernova]

I tried it and would like to give some feedback. I am no expert or even understand what stuttering is though.

First, the installer bat file does not work here. I have to manually register it.
Second, the output color is certainly different from EVR CP and everything else. I think madVR is wrong though, it kinda "washed out". Output level should be correct though. I tried the TV Level test clip and madVR is certainly not wrong. Or madVR is the only correct one here and all other renderer give me the same wrong so I never notice? I am not sure on that part.
Thrid, I didn't try all scaling method, but Lanczos and Spline both crash.
Finally, it certainly does not smooth. Compare to, say, EVR CP or mplayer.

Well, that's all. I'm on Windows 7 Beta 7000. ATi HD2600 with Catalysis 9.2

[madshi]

could you please also add comparison pics to the haali renderer? I guess that its used by many people as their standard renderer (at least for me :D ) thats why I'd like how your renderer compares to it.
Argh, another one added. Please use F5 to refresh.

What was input color space when using VMR9. I never seens such horrible VMR9/EVR output. Did you use YV12 or YUY2? If yes then it is very unfair comparision since on ATI NV12 is color space of choice. It produces very good results near that bad as on your screenshots.
I've used the standard which many decoders output by default, which is YV12. I don't think it's unfair. I didn't even know that ATI produces better results with NV12. And if even I didn't know that how do you think an average HTPC user will know that? Still, I'll look into how ATI compares with NV12...

First, the installer bat file does not work here. I have to manually register it.
Hmmm... Did you run the batch with admin rights?

Second, the output color is certainly different from EVR CP and everything else. I think madVR is wrong though, it kinda "washed out". Output level should be correct though. I tried the TV Level test clip and madVR is certainly not wrong. Or madVR is the only correct one here and all other renderer give me the same wrong so I never notice? I am not sure on that part.
It depends on your source. All the various sources use slightly different color formats/specs, different gamma transfer functions etc. madVR by default does what is needed for correct Blu-Ray playback. So for Blu-Ray maybe madVR is the only renderer with the correct colors? For SD content, however, what madVR does by default is incorrect. You can change the way how madVR does colorspace conversion by creating your own 3dlut file by using the "cr3dlut" tool. That gives you all the options you need including correcting the gamut of your display. A future madVR version will offer these settings in the GUI.

Thrid, I didn't try all scaling method, but Lanczos and Spline both crash.
Weird. Could you please try any other besides Lanczos and Spline? Lanczos and Spline both use 3 or 4 taps. All other algorithms use only 2 taps. Maybe that is the difference? On my XPSP2 Lanczos and Spline work fine.

Can anybody else reproduce a crash with Lanczos or Spline activated?

Finally, it certainly does not smooth. Compare to, say, EVR CP or mplayer.

Well, that's all. I'm on Windows 7 Beta 7000. ATi HD2600 with Catalysis 9.2
Ok, thanks for feedback. Improving motion smoothness is on the top of my priority list. However, the non-smoothness might also be caused by the HD2600 being too old/slow. Compared to my (entry level) HD3850, the HD2600 only has 1/3 of the shader power and only half of the memory bandwidth. You can try activating some of the "trade quality for performance" options. Maybe that helps smoothness for you?

[madshi]

Did you use YV12 or YUY2? If yes then it is very unfair comparision since on ATI NV12 is color space of choice. It produces very good results
I've just retested with ATI NV12. The results are exactly the same as with YV12 for me. Please note that such ugly chroma upsampling artifacts are usually only visible in specific scenes. Especially red fonts on black background.

(MPC-HC, XPSP2, VMR9, HD3850, Catalyst 9.1.)

[littleD]

Ati 3450
Winxp sp3 drv 9.2
Funny, have no big delay when opening video. But have massive lag when closing player. Sytem freeze for a long moment. Similar behaviour occurs when minimizing.
Win7 7057 drv 9.4
Installing madrenderer requires give exact path to madVideoRenderer.ax file in bat installer. No problems with closing and minimizing.
On both systems small lag when going to fullscreen or back to windowed (connected with aspect ratio). Seeking is fast.
Unfortunatly, i need dxva to work, so i will stick to evr :(

[Thunderbolt8]

Argh, another one added. Please use F5 to refresh.
thanks! both, haali and madvr look quite similar to each other, apart from that one can see that haali outputs a bit too much red.
but then im not that good on such graphic specific technical stuff, perhaps someone else sees differences?

is it actually possible technically to further improve the graphic quality of your renderer (hinting that it looks similar to haali, so this is basically best what can be achieved)? I mean at some point there must be a limit, when it looks exactly like the 'real' image looks like. but how is it possible that it actually looks different on each renderer? and how it is possible to perhaps make it look even better, but then again its not done by other renderers? (dont understand the process how such things can looks differently)

edit: cant seem to install it (winxp prof sp3), I get "LoadLibrary("madvideorenderer.ax") fehlgeschlagen - Das angegebene Modul wurde nicht gefunden." :S (windows login is listed as computer administrator).

*nvm, got it to work manually*

[madshi]

thanks! both, haali and madvr look quite similar to each other, apart from that one can see that haali outputs a bit too much red.
but then im not that good on such graphic specific technical stuff, perhaps someone else sees differences?
If you look at the "cF" comparison image from a further distance, the madVR image looks slighty smoother (less jaggied) to me than the Haali Renderer image. The difference is not big, though...

is it actually possible technically to further improve the graphic quality of your renderer (hinting that it looks similar to haali, so this is basically best what can be achieved)? I mean at some point there must be a limit, when it looks exactly like the 'real' image looks like. but how is it possible that it actually looks different on each renderer? and how it is possible to perhaps make it look even better, but then again its not done by other renderers? (dont understand the process how such things can looks differently)
With Blu-Ray the luma (brightness) information is stored in 1920x1080 pixels, however, the chroma (color) information is only stored in 960x540 pixels. So someone somewhere has to upscale those 960x540 chroma information to 1920x1080. There are a multitude of upscaling filters available, all have their advantages and disadvantages. That's why different renderers produce different results. madVR uses a very soft upscaler for chroma to get rid of jaggies. I don't think you can get much better results than what madVR already does right now for chroma upsampling.

[Thunderbolt8]

does soft here correspond to overall softness/sharpness of the image?

some small things:

- atm it doesnt seem to be possible to take screenshots in mpc-hc? (ffdshow & madvr)
- could you somehow integrate mpc's jitter display? atm it always displays 0ms all the time at playback, would be nice if it could display the actual information like with ffdshow & haali for example.

thanks!

btw. my installation problem seemed to result from a missing d3d .dll file (d3dx9_35.dll), which I had to download manually (dunno why, I have d3dx9_40.dll here though, is it newer?)

[Leak]

btw. my installation problem seemed to result from a missing d3d .dll file (d3dx9_35.dll), which I had to download manually (dunno why, I have d3dx9_40.dll here though, is it newer?)
Those d3dx9_xx DLLs are the regular Direct3D updates released every two to three months by Microsoft. You should get all of them if you run the DirectX web setup (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3) again.

(Yeah, it's still DirectX 9.0c, but look at the release date...)

[Thunderbolt8]

perhaps mine got somehow deleted or corrupted when windows once again crashed :P

btw. regarding all those madVR options (like resampling, dithering etc.) I guess the default choices are those which represent the displayed image most closely 1:1 (and I don't have to worry :D ) ?

[madshi]

does soft here correspond to overall softness/sharpness of the image?
When doing upscaling "soft" means less jaggies but also less sharpness. Fortunately our eyes are much more sensitive to brightness information than they are to color information. That's why e.g. LimitedSharpenFaster only modifies the luma (brightness) channel, but doesn't touch the chroma, AFAIK. So having soft chroma is actually a good thing. Having an overall soft image quality is not good, though. That's why madVR uses different scaling algorithms for chroma and luma.

- atm it doesnt seem to be possible to take screenshots in mpc-hc? (ffdshow & madvr)
True. Not implemented yet. I'm taking screenshots by doing PrintScreen.

- could you somehow integrate mpc's jitter display? atm it always displays 0ms all the time at playback, would be nice if it could display the actual information like with ffdshow & haali for example.
I don't know what exactly I'd have to do to make that work. I'm also not sure if jitter will make any difference once I implemented smooth motion display.

btw. my installation problem seemed to result from a missing d3d .dll file (d3dx9_35.dll), which I had to download manually (dunno why, I have d3dx9_40.dll here though, is it newer?)
Hmmmm... I guess _40 is newer than _35, but I don't really know why you had _40 but not _35!? Does anybody know?

btw. regarding all those madVR options (like resampling, dithering etc.) I guess the default choices are those which represent the displayed image most closely 1:1 (and I don't have to worry :D ) ?
If you display the source 1:1 in its original size, all luma scaling is turned off. The whole scaling options in the settings dialog have no effect in that situation. If you want to rescale the original resolution to something else, all the various filters have their own advantages and disadvantages, as I already said. E.g. Lanczos is the sharpest of the bunch, but also adds a lot of ringing to the image. Scaling is always a balance act between sharpness, aliasing and ringing. Just play with the filters and choose which looks best to your eyes...

[Hypernova]

I run the bat file by right click and choose run as admin, but it seems that does not work. Probably a bug on windows/UAC part, maybe. Your bat file work fine when run cmd as admin first then run the bat. So the problem is not on your part. :)

I think the scaling method crash may have something to do with something else entirely and not relate to the scaling itself. The thing is, I can't change the scaling method by go to MPC-HC options->external filter. When I change it there and play a file, it go back to default. When I right click while playing and change it by go to filter->madVR then close the file and reopen it, MPC-HC crash as soon as (I guess) the 96mb is filled and it try to display the video.

I may try what you suggest about the 3dlut later. I don't have a blu-ray file with me, so I can't test anything about that. I can't just use any 1080p video either right?

I would like to have choice in scaling though, so I probably keep checking back on madVR. Anyway, great work so far.

A little more info, I'm on Dell 3008WFP (2560x1600).

[Thunderbolt8]

I don't know what exactly I'd have to do to make that work. I'm also not sure if jitter will make any difference once I implemented smooth motion display.
I guess it wont make any difference to smooth playback, but to recognize when the movie runs out of sync. you can see it quickly as soon as the numbers pile up that something is working not fast enough, sometimes despite to what windows cpu load screen tells.

as it seems here, the fps numbers of movies I tried partially seem to vary. sometimes its ~24, another time > 30. it seems like when the system is not fast enough, then playback & displayed fps rate speeds up? haali renderer for example then slows down.

so jitter display would be a nice thing to spot speed problems on a quick & safe to tell glance, while otherwise it seems to be a bit more of guessing ("is this already running too slow/fast?") to be really sure (I'd compare it to the delay guessing of thd tracks of old eac3to versions, when correct delay for truehd wasnt yet supported)

[wozio]

I've used the standard which many decoders output by default, which is YV12. I don't think it's unfair. I didn't even know that ATI produces better results with NV12. And if even I didn't know that how do you think an average HTPC user will know that? Still, I'll look into how ATI compares with NV12...

For me average user also doesn't know how to use different than standard renderer and he doesn't know what the hell renderer is ;)

Custom renderers are for enthusiasts and changing output color space is easy for them.

If you want any hardware acceleration working best on ATI you must use NV12, be it hardware decoding, deinterlacing, post processing or color conversion. All current commercial decoders use nv12 on ATI.

Regards
Piotr

[zn]

Will this work on popular integrated video card Intel GMA X3100/X3000 (http://en.wikipedia.org/wiki/Intel_GMA#Table_of_GMA_graphics_cores_and_chipsets)?

[noee]

Here is some SD feedback, upscaled to 1080P, playback on a 1080P monitor. All of my source playback is AVC MKVs, 23.976fps.

XPSP3, Reclock, ATI HD2600 XT, CCC9.2, using MPC_HC's internal decoders.

I used the following settings to create the 3DLUT:

Input_Bit_Depth 8
Input_Video_Format NTSC_DVD YCbCr
Output_Bit_Depth 16
Output_Video_Format sRGB RGB_Video


With default upscaling, I get substantial tearing at 24Hz. Switching to 3tap Lanzcos or Spline helps. Haven't tried any other settings. When I switch to 60Hz, the tearing goes away. Vsync correction with Reclock does not seem to help so far.

Image detail is outstanding, I can't seem to see that EVR-CP is any smoother, but I have some 1080P home videos (AVCHD) and I will build a 3DLUT for those and try with those next.

[tetsuo55]

Would it be possible to get DXVA working with madVR?

You would obviously loose some of the extreme quality, but it could never be worse than VMR9/EVR

[haruhiko_yamagata]

Great work, specially the dithering is impressive. ffdshow's output is inferior just because it does not have dithering. I'm sure ffdshow converters calculate in 10bit and round to 8bit.

With "Allow output format change during playback" checked and "Connect to compatible filters only" unchecked,
I found two issues,
I cannot toggle resize during playback.
I cannot play DVD at all (DVD: Macrovision Fail) whichever the decoder is.
Reconnecting filters is the most difficult and important step in DirectShow.
Each video renderer has its own API to reconnect, and most open source DirectShow filters have workaround for each video renderer. This is a big mess. I don't want to add new workaround in ffdshow.
Please simulate one video renderer's behavior so that we don't have to code too much.
Also please document how to reconnect with your video renderer.
You may want to check out our svn and read Tffdecoder.cpp TffdshowDecVideo::reconnectOutput (which is a mess) or DScaler5's DSVideoOutPin.cpp.

My video card is nVidia 7900GS.

[Dark Shikari]

Great work, specially the dithering is impressive. ffdshow's output is inferior just because it does not have dithering.As I'm currently stuck with a burnt out graphics card, I have to output in RGB16 and as far as I can tell it most definitely has dithering.

[honai]

@Dark

this is not about dithering to RGB16, but dithering from YV12 (i.e. floating point) to RGB24/32. What you observed is something totally different, namely GDI dithering from RGB24 to RGB16. ;)

[Mark_A_W]

madVR getting united with MPC HC is not in the cards, because I want madVR to be media player independent. You know, although personally I'm using MPC HC for now, some people prefer ZoomPlayer.

But as explained in the first few posts of this thread, I'm planning to work on motion smoothness.

--------------------

Can I get some specific feedback, please? I'm especially interested in playback smoothness? Do you guys get stuttering with madVR? Or is your graphics card fast enough? How smooth or non-smooth is motion display for you currently? Especially if you set display refresh rate to 1:1 match with the source frame rate? Are the Beliyaal special builds a lot smoother for you, or only slightly so? Thanks!


I'm one of those who prefer Zoom Player, but Beliyaal's MPC HC builds are definitely smoother for me. It's enough to make me jump ship (but I am getting a glitch about once per hour).

With Beliyaal's build the Reclock tearing test line has less "micro" judder than Haali Renderer in ZP.

My setup:

Q6600
HD2600XT
Vista32
CRT monitor/projector running 1920x1080 interlaced at 95.904hz exactly.
CoreAVC for AVC
FFdshow using WMV9 decoder for VC-1
(Therefore no DXVA...ever!!)
Ffdshow doing RGB HQ for Haali Renderer
Reclock
Madflac for Flac (of course ;) )

With MadVR I get slight stutters and tearing. The tearing is odd, there are about 5 little tears, rather than the more normal big single tear towards the top of the screen (I get that with EVR back on XP).

If you can get it as smooth as Beliyaal's MPC builds, I'll be as happy as a pig in poo. :D It really sets the standard.

[leeperry]

test line has less "micro" judder than Haali Renderer in ZP.
from my experience, ZP's HR presenter just doesn't work.
MPC's HR presenter is far better(KMPlayer uses the same "borrowed" code).

[Thunderbolt8]

another thing, the subtitles field is greyed out in mpc-hc when rightclicking into the picture, while its selectable with haali (already reinstalled vsfilter after replacing the mediaplayer .exe file)

[STaRGaZeR]

Can you describe that weirdness for me? Is there some visible corruption? Or is the image just squeezed for a short time?

Yep, that's it. Also the image is frozen for 0.3 seconds or so.

That will require a combined effort on my side and MPC-HC side, but it should be possible to do. One problem is that I think the best place for some shaders would be in YCbCr space and madVR could offer that to custom shaders, while VMR/EVR can not. So MPC-HC currently does not support YCbCr shaders.

BTW, forgot to mention: Subtitle rendering is currently not supported. That needs to be added, too.

No problem if the shaders are custom, but it'll be nice if they could be managed (toggle, change between them, etc.) with keyboard or remote controller shortcuts.

That's already planned.

Cool.