madVR - high quality video renderer (GPU assisted)

[iSunrise]

Originally Posted by e-t172

No, actually, I stand by what I said. The calculator results are expressed in terms of absolute luminance, as well as BT.1886. However, madVR is unable to target some absolute luminance because it doesn't know what the luminance of 0% and 100% is. When you specify a pure power curve in madVR, it is applied in terms of pixel values, not luminance. So in the end, the output of madVR, after the pure power curve has been applied, is offset by the monitor's black level (madVR pixel value 0 = monitor black level). And when you offset a pure power curve with the monitor's black level, you get… a black-compensated power curve. QED.
...
The important thing here is that when configured in madVR a pure power law is applied to pixel values, but luminance ≠ pixel value. Instead, luminance = a*(pixel value)+b. The resulting luminance follows a black-compensated curve, even though the pixel values follow a pure power curve.
...
I totally agree, but considering very few calibration solutions support BT.1886 right now, most people won't have this ability. A good first step would be to have BT.1886 support in madVR, so that BT.1886 can be used even with a monitor using a different curve (e.g. black-compensated pure power law, sRGB function).

The question is how much work it would be for madshi to implement/adjust it to that. From my perspective, it would make the renderer a lot more bullet-proof, way more accurate and also, less confusing to setup and still adhere to what a renderer should do/should not need to do.

People that either want to calibrate or have already calibrated their monitors already have the values needed for madVR to work. madVR cetainly doesn´t need to offer another calibration solution, because it´s a renderer, but because of that it needs to be able to make use of the calibration results as best as possible for it to work correctly/accurately. Yes, I know that yCMS is supposed to do it, but I don´t like the workflow at all. I already have a calibration package that does it´s job, madVR should only offer something that actually has an added value rather than doing the same things again.

I for one would have had (or would have as I am still unsure of my results within madVR) an easier time if madVR allowed either sRGB or offer controls where I could input my calibration result´s 0% luminance (like 0.10cd/m²) and 100% luminance (80cd/m²) and use that as a base to let madVR calculate from.

I am right now completely unsure if my results are accurate. They certainly don´t look accurate. I suspect an error somewhere, but I`m not sure, where exactly and where to search.

If I am currently using the black bars/APL clipping test from AVS HD, I don´t have very good transitions between the lower and higher values within madVR (I gave the calibration package the LUT values to work with, which were measured with a Konica Minolta spectrophotometer at the factory to accurately correct the monitors ~2.20 native response to resemble an ideal 2.20 gamma curve), that is by using BT.709 and a 2.20 pure power curve in madVR like suggested. I have a rapid fall-off to black rather than a smooth transition. However, if I am calibrating to a Rec.709 profile with the LUT values I get a somehow brighter response in the darker areas and then going with a BT.709 curve in madVR and 2.20 gamma I am overwriting it with madVR´s gamma correction to a pure power curve between 2.20-2.60 and I suddenly have way better transitions in the 16 (reference black) and 25 values in that pattern, which I can also see in the films/content I watch. Everything just suddenly has a lot more depth to it. More shadow details that weren´t there before. Also, as an added bonus, because of the higher gamma, while I have more detail in the dark areas of the actual film, the black bars are WAY blacker then before. IPS panels have an edge-glow effect that reduce the visible contrast a bit. Even though I have a very good panel with extremely even brightness (max. deviation is like 1,5% in the corners) this offers a better experience in the end, because the corners are darker now.

I am not sure why that is. What makes this even more confusing is that outside of madVR (since I calibrated to 0-255 and not 16-235) I have perfect transitions within the dark values. I even decided to buy me a new i1 Display Pro to manually measure again, since it apparently offers more gamma precision than the DTP94B, but that should normally not be needed. But currently I don´t really have any explanation for the results I´m getting.

[therock003]

madshi any word on x64 support for madVR? Was that statement on the previous page about not coming for a couple of years any true?

[fairchild]

Can someone clear something up regarding MadVR and rendering times. When a movie is encoded at say 23.976 fps, and the display device has a refresh of 60hz, and the vsync interval is 16.67ms and the movie frame rate interval is 41.71ms....

What does my rendering times under the Average Stats need to be under? Should I maintain always under the vsync of 16.67ms or the movie frame rate of 41.71ms to not have any problems? Also should I ignore the max stats (5s) since this is usually very high for me.

I'm wondering because in order for me to get very low rendering times, I need to usually run DXVA-CB. If I run software decoding, my rendering times are usually much higher depending on the content.

[DragonQ]

Rendering time has to be below frame rate (quite a bit below ideally). Max stats can be ignored if you don't get frame drops/repeats once the video has "settled down" after a start/seek (after a second or so usually).

Obviously if you can render at ~25 ms then you're fine for 24p stuff but not for 25i/30i/50p/60p stuff.

[fairchild]

So below the frame rate interval correct? So in my example, as long as I'm below 41.71ms (this is the movie frame rate interval) then I'm fine? I don't think you meant if the movie is 24fps, then the rendering time has to be below 24ms?

Edit: thanks DragonQ, I checked some other sources and indeed the higher the file framerate (29.97, 30, etc) then the lower the movie frame rate interval is... So indeed as long as you are lower than the frame rate interval for a particular source, then you are fine. The lower the better.

[turbojet]

Originally Posted by madshi

If composition is enabled (and it can't be disabled in win8) and if you're not using overlay or FSE, then there's no way to "ignore" composition. Direct3D is redirected to composition internally in the OS in that situation. No way around it, except by disabling composition, using overlay or FSE.

I can't find the thread anymore but on stackoverflow it sounded like composition could be disabled on a per window basis without affecting other windows but maybe it did affect other windows and that's even a windows 7 explorer option.

If EVR can handle this then it might be considered a madVR bug. So please create an entry in the bug tracker, with an attached log file and a detailed description how to reproduce it (how to setup dual monitor so that the issue occurs etc). I can't promise I'll look at this soon, though, because multi-monitor issues are really hard for me to debug cause my development PC doesn't have a dual monitor setup. Please also write into the bug tracker description whether the problem does not occur if you directly start a new media player instance on the target monitor. (Probably it will work fine then?)

Will do. It doesn't have a problem with a new player instance.

According to the log your monitor has no display modes listed to switch to. My best guess would be that the cru utility results in madVR detecting a new display. Check the device stuff in the madVR settings.

You are right, a new device according to madvr and setting a display mode changes correctly.

You'd have to ask Microsoft about that.

It's not technically called aero peek from microsoft but they refer to it as taskbar thumbnails. I wrote up a bug report at http://bugs.madshi.net/view.php?id=39
It appears that VLC, WMP, WMC use hardware overlays by default and the thumbnails work fine they also allow screenshots and multiple instances. Perhaps the problem is hardware overlays are single output and madvr is it in this case. Seems there are ways to split the output, see http://stackoverflow.com/questions/8...ot-from-my-app

[Niyawa]

Originally Posted by therock003

madshi any word on x64 support for madVR? Was that statement on the previous page about not coming for a couple of years any true?

Yes. x64 is not really in madshi priorities right now AFAIK. He already has a "to-do" list so if we're getting a x64 version, it won't be soon. I mean, madVR has been around for years and people don't even talk about x64 right?

[leeperry]

BTW, I did quite a few changes and the new rendering path would appear to work fine on my 8800GS/306.81/XPSP3 setup after all..I'll now upgrade to the latest WHQL's to be on the safe side.

I'm just extremely annoyed by how hiccupy 24p@24Hz looks on a 10ms(real world measured figure) LCD, when OTOH it looks butter-smooth on a 96Hz CRT(thanks to the sample/hold effect I'd guess?) or a 48Hz DLP(due to MDA's I presume?). I get to see the "naked" individual frames and that's not smooth.....IIRC the 24p cadence was chosen to be the bare minimum off a 48Hz analog projector, not a fairly responsive LCD

And sure, this Sammy TV has a 200Hz BFI but the darn thing seems to be living a life of its own and that would not appear to be a 24Hz multiple...I've read ppl complaining about that on their TOTL 800Hz TV's and apparently even their 200Hz models would suffer from the same issue.

Just to clear things up, as long as the "dropped/delayed frames" & "presentation glitches" counters remain null, are these the absolute warranty that my PC is outputting a dead-smooth video signal?

It's just that 24p judder tests tend to ever so slightly hiccup randomly apparently, and what you call a "presentation glitch" seems to occur rather often with the old rendering path.....I've only seen it once with the new one. I'm just not sure whether I'm seeing the regular 24p judder, my PC is not outputting spot-on jitter or my TV(even in low latency "game" mode) is playing tricks on me

There's a price to pay for responsive LCD's, my caveman 46" 48Hz CCFL Hitachi had a slow LCD panel and that nicely blurred 24p I think..

Originally Posted by madshi

Yes.

OK, great! And will you also provide a way to set different scalers for SD & HD? The more I think about it, the more it seems videophool to me to splash out on a new graphic card just for 720p J3AR when it's actually the most needed for SD@1080p and that pretty much any graphic card can do that. It's just that constantly rolling scalers is a plain annoyance

I also presume that scaling using the CPU would be out of the question?

Originally Posted by madshi

That should be possible, although it might be ever so slightly lower quality then if done right in the first place.

Alright, hopefully you'll manage to implement MPEG1 chroma placement soon enough coz I've got a bunch of 720*576 files I'd really like to see in their best possible shape

Originally Posted by 6233638

most CRTs don't behave properly when the brightness control is turned down that low. (so they don't measure 2.40 at every point and are crushing shadow detail)

Correcto Mundo!

This test pattern looks fine on my 2.4 calibrated flat screen LG F900P:

This one does not, as <8 levels are just crushed to death:

so that means that dark scenes look great of course(you can't beat the blacks of a 20K:1 CRT), but if someone wears a black coat in a bright scene then it's just plain black with no detail whatsoever.....I'm just not sure if the poor thing is busted or if that's by design.

[iSunrise]

Originally Posted by leeperry

This test pattern looks fine on my 2.4 calibrated flat screen LG F900P:

This one does not, as <8 levels are just crushed to death:

so that means that dark scenes look great of course(you can't beat the blacks of a 20K:1 CRT), but if someone wears a black coat in a bright scene then it's just plain black with no detail whatsoever.....I'm just not sure if the poor thing is busted or if that's by design.

Both look perfect on the Eizo when using the factory calibrated sRGB profile. Very smooth transitions. I can even distinguish the inner black frame from the 1% black bar in the 2nd picture. Let´s hope that madshi includes sRGB, too.

I know what you mean with black coats and it´s irritating me every time. I always think there´s something wrong.

I guess that the problem is that coats or other dark clothing behave somewhat strange, even when the surroundings are well lit. Some of them are made out of cloth that just doesn´t reflect much light at all and that looks extremely strange when a person moves. It´s like a hole in your screen that moves, because you cannot make out any details. It´s not only coats, though, in Aliens there are also various metal elements that stay almost black (dead) no matter what. It can of course also be related to really bad encodes where they´ve crushed all the blacks.

[Schwartz]

Originally Posted by Niyawa

Yes. x64 is not really in madshi priorities right now AFAIK. He already has a "to-do" list so if we're getting a x64 version, it won't be soon. I mean, madVR has been around for years and people don't even talk about x64 right?

MadVR is so good that I'm fine with letting madshi do his thing however he wants. Good software is usually an effort of people doing exactly what they want to do.

But I'm also gonna throw my vote in for a x64 version. It may sound silly, but I don't like running software on an emulation layer by principle, even if it's an excellent one. Filters and resizers for example (used to use ffdshow) are much faster when you can use 64bit and all instruction sets.

[DragonQ]

Originally Posted by leeperry

so that means that dark scenes look great of course(you can't beat the blacks of a 20K:1 CRT), but if someone wears a black coat in a bright scene then it's just plain black with no detail whatsoever.....I'm just not sure if the poor thing is busted or if that's by design.

In my experience it's quite easy to beat the blacks of a CRT. All the CRTs I ever used had a "blooming" effect, like what you're describing. When the scene is brighter, blacks get lighter and shadow detail is reduced.

[ryrynz]

Originally Posted by Schwartz

But I'm also gonna throw my vote in for a x64 version.

Not really any point in voting, it's going to happen.. just not anytime soon.

[Niyawa]

Originally Posted by Schwartz

Filters and resizers for example (used to use ffdshow) are much faster when you can use 64bit and all instruction sets.

I'm not sure how an x64 version would improve performance in a noticeable way, but I do understand the thought of having your hardware running and using itself to it's full potential. As ryrynz mentioned though, we are going to get it just not soon.

I want to ask a question for those who knows about calibration and stuff. I'm using an LG Flatron E2260 that has some horrible colors when using the fabric calibration. The only preset that actually makes it more or less acceptable is sRGB (with white balance enabled). My question would be, is this sRGB the best option when available for all monitors or did it just happen to be the more optimal one here?

[e-t172]

Yes, assuming it really is calibrating to sRGB, it is the best setting. sRGB has the same primaries and white point as Rec. 709, which makes it very close to the ideal target for video. The only thing that's (slightly) different is the gamma. sRGB is the standard for computer monitors and in an ideal world all monitors would be calibrated that way from the start.

[leeperry]

BTW, what are the "present." average/max stats exactly? Jitter that should ideally be null? They don't reset when pressing CTRL+R so that doesn't really help if that's the case

[ikarad]

Originally Posted by madshi

Can't find this in the bug tracker?

.

What bug tracker?

[QBhd]

Originally Posted by leeperry

BTW, what's the "present." average stat exactly? the average jitter that should ideally be null? It doesn't reset when pressing CTRL+R so that doesn't really help if that's the case

presentation times... it's the average time madVR takes to present each frame. this should be lower than the movie frame interval.

QB

[Qaq]

Originally Posted by ikarad

What bug tracker?

http://madVR.bugs.madshi.net

[leeperry]

Originally Posted by QBhd

presentation times... it's the average time madVR takes to present each frame. this should be lower than the movie frame interval.

ok, thanks for the info.......then a jitter figure would be amazing if technically doable

[madshi]

Originally Posted by hdboy

Ah, FSE fixes it. But for usability purpose, I like to avoid FSE if possible.

Have you tried Overlay mode? Maybe that helps...

Originally Posted by hdboy

Sorry, how do I tell which queues are near empty?

Display the debug OSD (Ctrl+J) and check which queues have which fill state. If you don't know what to look for, just make a screenshot in the moment when frame drops occur, with the OSD on.

Originally Posted by therock003

madshi any word on x64 support for madVR? Was that statement on the previous page about not coming for a couple of years any true?

x64 support has been discussed before, please use search. I don't know if it will be months or years, but it'll not be soon.

Originally Posted by turbojet

It's not technically called aero peek from microsoft but they refer to it as taskbar thumbnails. I wrote up a bug report at http://bugs.madshi.net/view.php?id=39
It appears that VLC, WMP, WMC use hardware overlays by default and the thumbnails work fine they also allow screenshots and multiple instances. Perhaps the problem is hardware overlays are single output and madvr is it in this case. Seems there are ways to split the output, see http://stackoverflow.com/questions/8...ot-from-my-app

On a quick check I don't see anything helpful in that stackoverflow thread. There are also different kinds of Overlay. In any case, if some OS features work with windowed mode, but not with overlay, then it's most probably not madVR's fault. Maybe it would be possible to make such features work by adding in extra code, but I'm not willing to do that at this point in time.

Originally Posted by leeperry

BTW, I did quite a few changes and the new rendering path would appear to work fine on my 8800GS/306.81/XPSP3 setup after all..I'll now upgrade to the latest WHQL's to be on the safe side.

I'm just extremely annoyed by how hiccupy 24p@24Hz looks on a 10ms(real world measured figure) LCD, when OTOH it looks butter-smooth on a 96Hz CRT(thanks to the sample/hold effect I'd guess?) or a 48Hz DLP(due to MDA's I presume?). I get to see the "naked" individual frames and that's not smooth.....IIRC the 24p cadence was chosen to be the bare minimum off a 48Hz analog projector, not a fairly responsive LCD

And sure, this Sammy TV has a 200Hz BFI but the darn thing seems to be living a life of its own and that would not appear to be a 24Hz multiple...I've read ppl complaining about that on their TOTL 800Hz TV's and apparently even their 200Hz models would suffer from the same issue.

The sample-and-hold effect just blurs the image, it doesn't result in judder. If your Sammy TV is not smooth at 24Hz, while your CRT/DLP is then I would say that your Sammy probably doesn't support a native 24Hz refresh rate. It might internally apply 3:2 pulldown to 60Hz, I don't know. Is 60fps content butter smooth, as on your CRT? If so, you could try switching madVR to 60Hz for your Sammy TV and activate smooth motion FRC. But make sure you use the new FSE path, and I'm not sure if XP can swing it...

Originally Posted by leeperry

Just to clear things up, as long as the "dropped/delayed frames" & "presentation glitches" counters remain null, are these the absolute warranty that my PC is outputting a dead-smooth video signal?

If there are also no repeated frames and if your refresh rate matches your movie framerate, then yes, that should usually mean that your GPU output should be smooth - unless there's a bug in the GPU driver/hardware.

Originally Posted by leeperry

It's just that 24p judder tests tend to ever so slightly hiccup randomly apparently

How often? Once every couple of seconds? Or all the time (micro-judder)?

Originally Posted by leeperry

OK, great! And will you also provide a way to set different scalers for SD & HD?

This has been asked and answered multiple times already.