madVR - high quality video renderer (GPU assisted)

[6233638]

If dithering is not disabled for a pure black screen with yCMS calibration then that means that the yCMS 3dlut probably produces a fractional black level value for some reason. I don't know why. It could be a problem with yCMS, or a result of your display needing black correction of some sort, or some sort of inaccuracy in madVR's 3dlut processing. In the first 2 cases there's probably not much I can do about it.It must not be getting disabled for black if I'm seeing an elevated black level. My display turns a zone completely off if it's sent zero, but the zones only turn down to a very low level if it's above zero - even something like 0, 0, 1.

The LUT I am using is relatively simple, and is only used to fine-tune the gamma response of my display; grayscale and gamut are actually worse if I try to use yCMS for that - at least via the controls in the madVR settings window.
I displayed test patterns in my media player, measured them in CalMAN, and adjusted the yCMS values until each point measured exactly 2.40 gamma.

red, Yxy, 0.2126, 0.640, 0.330
green, Yxy, 0.7152, 0.300, 0.600
blue, Yxy, 0.0722, 0.150, 0.060
white, Yxy, 1.0000, 0.312713, 0.329016

5, Yxy, 0.00080, 0.312713, 0.329016
10, Yxy, 0.00545, 0.312713, 0.329016
15, Yxy, 0.01415, 0.312713, 0.329016
20, Yxy, 0.02750, 0.312713, 0.329016
25, Yxy, 0.04550, 0.312713, 0.329016
30, Yxy, 0.06950, 0.312713, 0.329016
35, Yxy, 0.09900, 0.312713, 0.329016
40, Yxy, 0.13300, 0.312713, 0.329016
45, Yxy, 0.17300, 0.312713, 0.329016
50, Yxy, 0.21900, 0.312713, 0.329016
55, Yxy, 0.27500, 0.312713, 0.329016
60, Yxy, 0.33200, 0.312713, 0.329016
65, Yxy, 0.40000, 0.312713, 0.329016
70, Yxy, 0.48100, 0.312713, 0.329016
75, Yxy, 0.55800, 0.312713, 0.329016
80, Yxy, 0.64250, 0.312713, 0.329016
85, Yxy, 0.73160, 0.312713, 0.329016
90, Yxy, 0.82350, 0.312713, 0.329016
95, Yxy, 0.91250, 0.312713, 0.329016
100, Yxy, 1.00000, 0.312713, 0.329016

I am not able to set a zero point in the yCMS dialog - the save button is disabled if I try to do that, so one would assume it is being set to zero. After all, who wants an elevated black level?

Back when I was using external hardware which let you write your own custom LUTs as a text file, no matter what the lowest measured value in the LUT was, I would always set black to 0, 0, 0.

If you are using interpolation/smoothing on the LUT, it also needs to follow the curve from the lowest point of data (typically 10%) down to the lowest value in the LUT rather than trying to converge on 0, 0, 0, otherwise you can end up with highly distorted values near black.
It should look something like this (http://i.imgur.com/TQjhcLW.png) (video levels) rather than the values from 10% down converging at black.
In that example, all values would be considerably darker than they should be, and you would have red tinted shadows below 10% if that were the case. You would be surprised at how many calibration packages made that mistake - it's why I preferred to manually calculate the LUTs myself.


While values near black may need to be quite elevated for proper shadow detail to be visible, as in the example I posted above, I can't think of a reason you would not want black to be zero.

[NicolasRobidoux]

http://www.avsforum.com/t/1477339/so-youve-built-your-htpc-now-what-is-next-how-to-get-the-ultimate-picture-and-sound-quality-from-your-htpc-madvr-svp-xbmc-mediabrowser-jriver#post_23430408

[ryrynz]

http://www.avsforum.com/t/1477339/so-youve-built-your-htpc-now-what-is-next-how-to-get-the-ultimate-picture-and-sound-quality-from-your-htpc-madvr-svp-xbmc-mediabrowser-jriver#post_23430408

I'm noticing Jinc in the Image upscaling of a diagonal pattern has some parts where the lines aren't completely straight.
The line which goes from bottom left to top right has X patterns which form a star and the other line has twelve smudgy strike out lines.
Is this effect something that could be improved?

[madshi]

It must not be getting disabled for black if I'm seeing an elevated black level. My display turns a zone completely off if it's sent zero, but the zones only turn down to a very low level if it's above zero - even something like 0, 0, 1.

The LUT I am using is relatively simple, and is only used to fine-tune the gamma response of my display; grayscale and gamut are actually worse if I try to use yCMS for that - at least via the controls in the madVR settings window.
I displayed test patterns in my media player, measured them in CalMAN, and adjusted the yCMS values until each point measured exactly 2.40 gamma.

I am not able to set a zero point in the yCMS dialog - the save button is disabled if I try to do that, so one would assume it is being set to zero. After all, who wants an elevated black level?

Back when I was using external hardware which let you write your own custom LUTs as a text file, no matter what the lowest measured value in the LUT was, I would always set black to 0, 0, 0.
If you think this could be a bug in madVR then please feel free to create an entry in the bug tracker. Then I'll have a look when I find some time. If it's a bug in yCMS then there's nothing I can do. I don't even have the yCMS source code. And even if I had, I wouldn't know how to fix it.

http://www.avsforum.com/t/1477339/so-youve-built-your-htpc-now-what-is-next-how-to-get-the-ultimate-picture-and-sound-quality-from-your-htpc-madvr-svp-xbmc-mediabrowser-jriver#post_23430408
Yep, I know... :)

I'm noticing Jinc in the Image upscaling of a diagonal pattern has some parts where the lines aren't completely straight.
The line which goes from bottom left to top right has X patterns which form a star and the other line has twelve smudgy strike out lines.
Is this effect something that could be improved?
I think this is probably an distorted/bad screenshot. Try downloading the test pattern video, I don't see these strike out lines here.

[6233638]

If you think this could be a bug in madVR then please feel free to create an entry in the bug tracker. Then I'll have a look when I find some time. If it's a bug in yCMS then there's nothing I can do. I don't even have the yCMS source code. And even if I had, I wouldn't know how to fix it.I'm guessing it'll be however yCMS is interpolating when creating the LUT.

There's no way to have madVR override this so that black is always completely black? (either in the LUT, or after it?)
E.g. have madVR run a known black reference through yCMS, and always set that value as zero.

It's only a very minor gamma correction I'm doing for the sake of correctness rather than being something my display needs, so I suppose I can stick to telling madVR my display is already calibrated.

It sounds like people are also having this problem when creating LUTs via other tools like ArgyllCMS, so I wonder if it's something worth investigating?

You shouldn't have to adjust the LUT at all, just set the lowest value that it outputs as zero, rather than being slightly elevated.



I wish the LUT process was a lot easier where you could just set RGB output values, rather than adjusting input values. It's less automated, but it makes it trivial to get good results. Create a patch of color in your image editor of choice, adjust the RGB values until it matches your target, and enter those values in the LUT.

I suppose that gets complicated once you're looking to do a lot of points for gamut calibration rather than just grayscale and gamma, but it's still so much simpler to say that 100% blue needs 16,32,250 to be accurate than anything else, for example. (though you would probably want to use at least 10-bit values)

[madshi]

As I said, if you think this is something I should fix in madVR, feel free to create an entry in the bug tracker. I don't have time to look at this *now*, and I will forget about it, if it's not in the bug tracker.

[v0lt]

Hmmmm... Is this your own decoder, respectively the MPC-HC decoder? Or LAV? Or something else? I can look into this, if you think it might be a renderer issue, but I'd need to be able to reproduce it somehow.
I use a modified MPC-BE.
mpc-be_3994_YV16.7z

[madshi]

I use a modified MPC-BE.
mpc-be_3994_YV16.7z (http://www.mediafire.com/download/5j9ps8siqrrlr7t/mpc-be_3994_YV16.7z)
From looking at my source code and a test madVR log it seems to me that madVR is doing its part correctly. Then I've dumped out a frame coming from the MPC-BE test build, and the lower half of the chroma information is zeroed out - while it should be around 0x80 for a black screen. So this looks very much like it's MPC-BE's fault. The luma information looks correct, the size of the frame, too, but the chroma information is stored incorrectly. The 2nd half is zeroed out, the first half is not correct, either.

Unfortunately LAV doesn't seem to support YV16, so we can't use LAV to double check. But I'm pretty sure this is MPC-BE's fault.

[v0lt]

From looking at my source code and a test madVR log it seems to me that madVR is doing its part correctly. Then I've dumped out a frame coming from the MPC-BE test build, and the lower half of the chroma information is zeroed out - while it should be around 0x80 for a black screen. So this looks very much like it's MPC-BE's fault. The luma information looks correct, the size of the frame, too, but the chroma information is stored incorrectly. The 2nd half is zeroed out, the first half is not correct, either.
Thank you. Most likely you're right. If I take an uncompressed YV16 AVI file, the decoder is not used and the picture is normal.
twogradients_RAW.rar (http://www.mediafire.com/download/a63hb452v1k39xz/twogradients_RAW.rar)

Unfortunately LAV doesn't seem to support YV16, so we can't use LAV to double check. But I'm pretty sure this is MPC-BE's fault.
LAV contains the same code as in the modified MPC-BE, but this code is disabled.

[madshi]

Then maybe nevcairiel could help out fixing that code?

[nevcairiel]

When i enable YV16 in LAV, it works just fine with madVR. If you already copy my code, at least do it correctly. ;)

[madshi]

Haha! :)

Why are you not using YV16, btw, nev? Recently you said you preferred YV24 because it's planar. YV16 is planar, too, unlike the other 4:2:2 formats. So shouldn't you have a preference for YV16 over the other 8bit 4:2:2 formats, too? Not important for me, just wondering...

[nevcairiel]

When i implemented YV16, madVRs YV16 support was still broken (planes flipped, i belive). You fixed it later, but it got never enabled in LAV. Maybe i'll do that soon.

[v0lt]

When i enable YV16 in LAV, it works just fine with madVR. If you already copy my code, at least do it correctly. ;)
Sorry, the code is different. Why the same method works for YV12 and YV24, but does not work for YV16? :confused:

[13ack.Stab]

Hi, madshi.

I've been using madVR for many months now, and I absolutely love it. I've recently encountered crashes, however, while playing a particular video file. From what I can tell, the crash may not occur in madVR itself, but in XySubFilter instead -- even though madVR generates a crash report. As I'm not sure what the culprit is, I decided I would post here instead of creating an issue on the bug tracker.

The crash occurs when watching a specific video normally, and with little warning. An exception is raised in the subtitle thread, so I would imagine the problem lies with rendering the large volume of animated text at the time of the crash.

I've compressed and uploaded the crash log, the madVR log, and a short clip of the video that crashes. You can grab them on MediaFire (http://www.mediafire.com/download/n1f05xpa3fobvq8/madVR%20Crash%20Resources.zip).

Thanks for your time and assistance.

[Pulstar]

using xy-VSFilter that file leaked almost 2 gigs of memory and made the system very unstable.

http://i39.tinypic.com/11qtst1.png

The subtitle file is the culprit here. What a piece of shit format. You can extract it using a GUI tool and convert it to SRT if you don't mind losing all the fancy schmancy text formatting.

[annovif]

Thank you Huhn and Thx-UltraII for your advices . I'm doing the tests and for now the best solution for me is this :

coreavc (or lav) setted 16-235 in input and in output --> madvr setted in 0-255 --> gpu Ati setted in rgb full (4:4:4) (thank you 6233638:)) --> Radiance Processor input setted in rgb video and ycbcr 4:2:2 in output -> pj

Maybe I'm doing something wrong, because in this way my pj settings in brightness and colour have to be very high, but i think the image is good (i think:))

[kazuya2k8]

@13ack.Stab not madVR's fault. tested with EVR w/ xy-Vsfilter and still crashed.

EDIT: Tested with MPC-HC's ISR vsfilter and it didn't crash. Either the script is really bad or need some optimizing in xy-Vsfilter.

[THX-UltraII]

Guys, I m running a projector as a display device. My projector has only greyscale and gamma correction but no CMS. I own a Chromapure calibration kit with a i1 Display Pro III meter. I calibrated by gamma and greyscale which is pretty good now. The primaries and secondaries on my projector are pretty good out-of-the-box but I want to see if I can fine-tune it.

Is there a manual somewhere how the CMS of madVR works? I have no idea how to begin with this.

[toniash]

Where do I can download the last test version with debanding?

[Schwartz]

Running 0.86.11, I experienced a crash. Having two instances of MPC-HC open and drag-dropping an .mkv onto one of them is what preceded the crash. The madVR crash report (http://www.filedropper.com/madvr-crashreport).

[huhn]

Where do I can download the last test version with debanding?

http://forum.doom9.org/showpost.php?p=1655679&postcount=20990

edit: one question about 10 bit output.

if i remember it was not possible to output bi matched 10 bit over directx 11 right?

first of all nvidia says this:

NVIDIA Geforce graphics cards have offered 10-bit per color out to a full screen Direct X surface since the Geforce 200 series GPUs. Due to the way most applications use traditional Windows API functions to create the application UI and viewport display, this method is not used for professional applications such as Adobe Premiere Pro and Adobe Photoshop. These programs use OpenGL 10-bit per color buffers which require an NVIDIA Quadro GPU with DisplayPort connector. A small number of monitors support 10-bit per color with Quadro graphics cards over DVI.

http://nvidia.custhelp.com/app/answers/detail/a_id/3011/related/1

the point is the geforce 200 series this card is directx 10 so directx 10 supports 10 bit output too (or nvidia lies). but does it behavior like directx 11 or is there a chance? i mean it is the forgotten directx version X-)

[djfred93]

edit: one question about 10 bit output.

if i remember it was not possible to output bi matched 10 bit over directx 11 right?

first of all nvidia says this:



http://nvidia.custhelp.com/app/answers/detail/a_id/3011/related/1

the point is the geforce 200 series this card is directx 10 so directx 10 supports 10 bit output too (or nvidia lies). but does it behavior like directx 11 or is there a chance? i mean it is the forgotten directx version X-)

I think it's a hardware capability but it's not activated. It's the same for ati card. It's activated only the pro version card.

Sorry for my poor english.

[huhn]

that's not true normal cards can do 10 bit and evr can output 10 bit with normal cards but there is a problem with directx 11. no full control of the output picture.

and nvidia says clearly that normal cards can use 10 bit with directx.

of cause normal amd cards support 10 bit with directx too but the point is that this should work with directx 10 because the nvidia 200 is a dirctx 10 card. the the problem is 3d is on a hole different level...

[Mangix]

madVR is DX9 for now. So don't get your hopes up.

[6233638]

there is a problem with directx 11. no full control of the output picture.What do you mean by this?

madVR is DX9 for now. So don't get your hopes up.Unless I am mistaken, I seem to remember older builds of madVR offering DX11 output.

[huhn]

yeah with "wrong" color.

you can't control the output with directx 11. if i remember correctly.

and most likely that's why it is no longer in general settings.
0.60-0.70 should have this option try it out.

and that's why i ask if directx 10 is a option or at least worth a look at.

[annovif]

http://www.avsforum.com/t/1471169/madvr-argyllcms;)

[deSiem]

Got a new plasma the vt65 (uk vt60) and started to toy around with mpc hc with internal lab and madvr.

This is on a win7 with an intel hd4000. The main thing I'm trying to get my head round is the rgb range. Done a bit of reading and testing using the avs black clipping mp4. In this video black levels are represented by flashing bars numbered from 2-25 where 16 represents video black.

I'm just trying to see if I understand all I read on this correctly.

When I set the display to 0-255 and I set the gpu display output to to 0-255 and set madvr to the same again this causes the flashing bars from 2-16 to stop flashing as 0 rgb black is represented by bar 16 now.
Do i understand it correctly?

[Mangix]

Unless I am mistaken, I seem to remember older builds of madVR offering DX11 output.

That was a feature that madshi tried out in order to help with nvidia driver issues. It didn't actually make madVR a DX11 application. It was still DX9 but used a single feature only found in DX11. Very similar to how Valve uses DX11 features while the source engine is still very much DX9 based.

[huhn]

Got a new plasma the vt65 (uk vt60) and started to toy around with mpc hc with internal lab and madvr.

This is on a win7 with an intel hd4000. The main thing I'm trying to get my head round is the rgb range. Done a bit of reading and testing using the avs black clipping mp4. In this video black levels are represented by flashing bars numbered from 2-25 where 16 represents video black.

I'm just trying to see if I understand all I read on this correctly.

When I set the display to 0-255 and I set the gpu display output to to 0-255 and set madvr to the same again this causes the flashing bars from 2-16 to stop flashing as 0 rgb black is represented by bar 16 now.
Do i understand it correctly?

2-16 should be black in that sample. if this is the case you have done it right.

[pirlouy]

I've created a thread (http://forum.doom9.org/showthread.php?t=169928) for madVR interaction with Samsung TVs if you're interested...

[THX-UltraII]

Is it possible to output x.v.Color from my HTPC when madVR is used with MPC-BE and when using a ATI HD7950 GPU? I ask this because my display device supports x.v.Color and I want to check out some MI4K (Mastered In 4K) Blu-Ray content. But if you want to be able to see the larger color space x.v.Color the chain must be correct so:

MI4K discs (which can be played with MPC-BE) => output x.v.Color from HTPC => display device that supports x.v.Color.

An example of a current setup that can do this is:
MI4K Blu-Ray discs => PS4 => Sony VW500 projector.

[huhn]

first of all you should look if your beamer is capable of showing colors out of srgb. you can see that after calibration. and at the end it "doesn't matter" if you output it with xv color or rgb.
the created 3d lut should use as many informations from the x v color spaces as possible.

but i'm missing a lot of knowledge in this case so...

at first you should make sure that your device can show colors which excessed rgb.

[Werewolfy]

I installed Windows 8.1 yesterday and I have a problem with refresh rate. When the video goes in fullscreen exclusive mode, refresh rate always switch from 24hz to 23hz.

I have read that this issue was fixed in madVR 86.3, I don't understand why it still happens now. I have tried the display mode switcher from madVR but it doesn't fix the issue. It works well in fullscreen overlay mode but never in exclusive mode.

[Asmodian]

I believe this is a known problem but with the video drivers. MadVR tells them to switch to 24hz correctly but somehow the drivers decide to switch to 23hz instead when in FSE.

[Werewolfy]

Ok I thought it was completely fixed now... Is there any downside not using fullscreen exclusive mode but fullscreen overlay mode instead if I don't experience tearing?

[6233638]

Ok I thought it was completely fixed now... Is there any downside not using fullscreen exclusive mode but fullscreen overlay mode instead if I don't experience tearing?I just use regular windowed mode (no overlay) because it's still switching to 23/59 rather than 24/60 in FSE mode.

The only real difference is that power consumption is a bit higher, and seeking performance is not as smooth.

In Windowed or Windowed Overlay mode, seeking freezes up every so often if I'm just holding down a key to seek through a video. FSE mode does not have this problem for me.

[Werewolfy]

Thanks for the information ;)

I use overlay mode because I have better rendering times but it doesn't make a huge difference. Too bad we have those nasty issues with Windows 8.1, I really don't know why Microsoft has changed a thing that worked perfectly before.

[6233638]

Too bad we have those nasty issues with Windows 8.1, I really don't know why Microsoft has changed a thing that worked perfectly before.Maybe it's an unintended consequence of whatever they had to do to get seamless refresh rate switching to work?

Supported hardware (tablet devices right now) is able to switch from 60Hz to 48Hz when playing films without any indication that the refresh rate has changed. This gives you judder-free playback of films, and reduces power consumption.

[MSL_DK]

Hi ... With the latest test builds, I experience dropped frames. It is not only with the latest version, it is also with the other you have uploaded. I did not have problems with dropped frames before now. What can I contribute in connection with troubleshooting?

12 minutes in the movie:
18 presentation glitches
121 dropped frames

I am pretty sure that you have made a fault with the Smooth motion switch. If I enable Smooth motion I get dropped frames, if I disable Smooth motion everything plays fine without droped frames

[Asmodian]

I think this might due to the interaction of smooth motion and fade detection, frames that had been generated twice by smooth motion (which should be dropped) being dropped and showing up in the OSD. If you set the fade level to the same as the normal level for debanding you should stop seeing dropped frames in the OSD.

madVR also needs to rerender the last 5 frames when it detects a fade so fade detection when debanding might cause real frames drops when using small buffer sizes.

[leeperry]

BTW, we've often discussed what a good GPU for mVR would be, the answer was the GTX660 and IME a factory overclocked HD7850 does the trick very nicely :)

I constantly see gamers whining that their CPU acts a bottleneck in games showing all kinds of fps comparisons to make their point, but I'm very surprised to see that the Haswell Pentium's are essentially just as fast as their old S775 quads in many benchmarks: http://www.cpubenchmark.net/high_end_cpus.html

I've also seen mVR users trying to keep their GPU in low power state in order to save a few watts, but for instance the 55€ Pentium G3420 comes with a 54W TDP and would appear to be an ideal choice for foobar+mVR users?

When using DXVA2 CP decoding, the only things running off the CPU would be the audio decoding/post-processing, Reclock, LAV Splitter and mVR's deinterlacing basically...54W does sound very yummy :)

[nevcairiel]

Faster CPUs don't consume more power, unless you actually give them more stuff to work on.
In fact, high-end CPUs are usually of a better silicon quality, which offer less leakage, and thus less power use.

Buying a slower CPU to save power is just wrong, it doesn't work. At best you use the same power as a faster CPU, at worst, even more. That is of course, assuming the same workload. Can't compare 100% load on both CPUs, have to compare the same workload, ie. video playback, and not benchmarks.

[huhn]

the tdp is misleading it only shows the theoretical max power usage but typical usage and prime benchmarking are normally lower and the g/a-pu is a part of the tdp too.

2 cores should spare power in idle that's about it when the same architecture is used.

[leeperry]

Indeed, TDP is highly theoritical and I realize that a 2X/3X pricier CPU could yield a (slightly?) lower watt consumption than a G3420 for the same job, but it might very well be the same story as with the most efficient Platinum/Titanium 80+ PSU's that cost a lot more than a regular Bronze 80+ and come with a very low ROI in comparison. This would require a lot of real-world power measurements I guess.

All I'm seeing is that a 55€ 54W Pentium G3420 would appear to be almost as fast as my old 95W Q9450 in many benchmarks and I barely see the CPU load of the latter going over 15% in the Windows Task Manager while watching movies.

[Mangix]

Faster CPUs don't consume more power, unless you actually give them more stuff to work on.
In fact, high-end CPUs are usually of a better silicon quality, which offer less leakage, and thus less power use.

Buying a slower CPU to save power is just wrong, it doesn't work. At best you use the same power as a faster CPU, at worst, even more. That is of course, assuming the same workload. Can't compare 100% load on both CPUs, have to compare the same workload, ie. video playback, and not benchmarks.

Underclocking helps regardless.

[beter]

When "present several frames in advance" in "exclusive mode settings" is disabled, DXVA2 decoder isn't usable anymore.
Is it a technical limitation, or just a bug?

Thanks.

[huhn]

When "present several frames in advance" in "exclusive mode settings" is disabled, DXVA2 decoder isn't usable anymore.
Is it a technical limitation, or just a bug?

works fine for me. the backbuffer stays at 0-1 but there aren't any framedrops all.

but changing back to "present several frames in advance" make you trouble in exclusive mode until i restart the player.

[pirlouy]

All I'm seeing is that a 55€ 54W Pentium G3420 would appear to be [...]
...an excellent value for the money if we consider a lot of applications can't handle more than 1 thread, still today (task manager still shows 50% use with my 2 cores CPU when working hard with some applications).