madVR - high quality video renderer (GPU assisted)

[FoLLgoTT]

all that is needed to trick our brain is proper grayscale, D65 white point, ±2.3 gamma and 100 IRE gamut conversion.

I think you missed the point. The question was not why to calibrate if there is no 100% accuracy with current sensors, but why to calibrate if the model itself is flawed. There is no correct absolute greyscale, D65 and gamut. For every person this is more or less different and also depends on the emitted spectrum of the display. It is not a matter of measuring accuracy, but a matter of concept.

[Thunderbolt8]

The levels controls in ffdshow only have any effect if ffdshow outputs RGB. madVR does not support RGB input, it only supports YV12 input. So there's no way you can make use of the ffdshow levels controls when using madVR, because if ffdshow outputs YV12, the ffdshow levels controls have no effect whatsoever.
ok thanks! though now Im wondering a bit what I should use as output with madvr. tv levels seems to be logical, but imho the picture looks a bit too bright for me then. it then looks like as when choosing PC levels with haali, and tv levels of haali looks like PC levels output with madvr. so I wonder why that difference, does haali do wrong outputs here or perhaps does haalis levels get influenced with those ffdshow settings?

[madshi]

This is a good question. I think the standard observer is sufficient for most cases. Our eye is not as precise as a spectrophotometer and it strongly depends on environment and many other factors. I think it is sufficient to calibrate the necessary values into a small range which is small enough that no difference can be seen with a before/after comparison with my own eyes.
Small range of what? Small range of the wrong concept? You are not consequent here. If you consequently follow your original argument it should be better not to calibrate to any standard, but to "turn the wheels" yourself without any reference to anything, just to your subjective linkings.

And here comes my reasoning why your argument doesn't hold merit: The final movie mastering is done in the studio. There a guy (or girl) watches the movie on a professional monitor which is (or at least should be) calibrated carefully to the existing standards. Now it doesn't matter much if the standards are perfect or not. The guy deciding on final color tone etc watches the movie and makes his decisions based on what he sees on his monitor which is calibrated to the standard. So if we want to see what the movie makers wanted us to see, we have to carefully calibrate our displays to the same standard, faulty or not. If we don't do that, we'll see different colors than the movie color guy saw on his professional monitor.

Now you can say that everybody sees colors differently and you are probably right with that. However, it doesn't really make any difference in this discussion! Why? Because the guy who decides on color mixing sees both the movie and also real life with the same eyes. E.g. let's say he sees more red than the rest of us humans. Does that mean that he mixes the movie in such a way that it contains less red? No! Not at all. Because he sees too much red in real life, too. So too much red is what looks natural to him. Because of that it doesn't matter at all whether he sees colors differently than we do.

[leeperry]

I think you missed the point. The question was not why to calibrate if there is no 100% accuracy with current sensors, but why to calibrate if the model itself is flawed. There is no correct absolute greyscale, D65 and gamut. For every person this is more or less different and also depends on the emitted spectrum of the display. It is not a matter of measuring accuracy, but a matter of concept.
well no I was actually answering that question, I think :o
it's flawed and it'd require weekly recalibrations...so there's no need to reach super high mathematical accuracy, but well madshi will do his best to reach it anyway :D

but as I understand it, it'd all be done in cr3dlut.

[madshi]

ok thanks! though now Im wondering a bit what I should use as output with madvr. tv levels seems to be logical, but imho the picture looks a bit too bright for me then. it then looks like as when choosing PC levels with haali, and tv levels of haali looks like PC levels output with madvr. so I wonder why that difference, does haali do wrong outputs here or perhaps does haalis levels get influenced with those ffdshow settings?
Haali's controls are for input levels (which levels is the movie encoded to?). madVR controls are for output levels (which levels does the display want to have?).

[madshi]

it's flawed and it'd require weekly recalibrations...so there's no need to reach super high mathematical accuracy
As I already said, once we get laser light sources, the need for weekly recalibrations should be gone. Furthermore it's not about super high mathematical accuracy. It's about reasonably high accuracy throughout the whole range of colors and brightnesses etc. If you only calibrate to one stimulus levels, you'll have reasonably high accuracy at the stimulus level, but you may have very big deviations at other stimulus levels. Reasonably high accuracy is what we are targetting for, but please at every stimulus level!

[leeperry]

it's not about super high mathematical accuracy. It's about reasonably high accuracy throughout the whole range of colors and brightnesses etc.
alright, sounds like a plan! looking forward to it http://forum-images.hardware.fr/images/perso/ayuluna.gif

[FoLLgoTT]

Small range of what?

Of the standard used.

So if we want to see what the movie makers wanted us to see, we have to carefully calibrate our displays to the same standard, faulty or not.

I partially agree with that. But only because it is the only thing we can do. More in the next passage...

If we don't do that, we'll see different colors than the movie color guy saw on his professional monitor.

Yes, but my point is that even if we calibrate our display to the standard, we probably don't see it as we would see it on this particular mastering monitor. If the spectrum of the display differs our perception may be slightly different. CRTs vor example have a very different spectrum to UHP bulbs of digital projectors. This standard is only valid if we view our movies with the exact spectrum used when the movie was mastered.

If there would be a standard for the spectrum of displays, we really could watch our movies as intended to. But with the current situation there is just this unknown additional error. At home we are not able to quantize it. We would need an analysis of our individual perception and the impact of the spectrum used. So we could calibrate our display in that way that our (!) eyes percieve the colors like the colors of the mastering monitor.

The next problem is that we had to know the model of mastering monitor for each movie...

[leeperry]

the spectrum of the display differs our perception may be slightly different.
[..]
The next problem is that we had to know the model of mastering monitor for each movie...
spectrum of the display? not gamut?

coz we more or less know what they use in mastering houses : http://forum.doom9.org/showthread.php?t=139389

but as long as we won't be able to take the primaries/secondaries saturations(measured by Color.HCFR) in account into the 3D LUT, it won't really be meaningful...but I'm beating a dead horse here :D

[madshi]

If there would be a standard for the spectrum of displays, we really could watch our movies as intended to. But with the current situation there is just this unknown additional error. At home we are not able to quantize it. We would need an analysis of our individual perception and the impact of the spectrum used. So we could calibrate our display in that way that our (!) eyes percieve the colors like the colors of the mastering monitor.

The next problem is that we had to know the model of mastering monitor for each movie...
For my taste you're thinking too much about what we have today. All of that should change once we get pure color laser light sources. They should have a clearly defined spectrum, I think.

Anyway, even with current hardware we should at least *try* to get as near as possible to the standard. If we don't do that (by creating/using an as good as possible CMS) the calibration mismatch errors and the spectrum/perception related errors etc may all add up to the wrong side of things.

Why don't we ignore the things we can not measure (we can not change them, anyway) - and try to get those things right that we can measure?

[FoLLgoTT]

spectrum of the display? not gamut?

I mean the electromagnetic spectrum (http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg) of the primary colors. The spectrum is very different for each display type. Some has narrow but high peaks. And others have broader but low peaks. Basically only the area is important. But since the spectrums for green, red and blue partially overlap the perception can be different depending to your eyes.

[FoLLgoTT]

For my taste you're thinking too much about what we have today. All of that should change once we get pure color laser light sources. They should have a clearly defined spectrum, I think.

I don't think this will be the case in the next 50 years for every display out there. ;)

Why don't we ignore the things we can not measure (we can not change them, anyway) - and try to get those things right that we can measure?

I agree. It is a (small) problem without a solution. So we can only do our best and calibrate our displays using the standard with more or less accurate sensors. :)

[nlnl]

Quote:
Originally Posted by psme View Post
Great work! But there is heavy tearing at 24p output, both windowed and full screen. EVR or Overlay works fine without tearing. At 60Hz output, madVR don't tear, but I must play 24p source at 24p output!

My system, E6600 C2D at 3G, Win XP SP2, ATI 4850 512M (core 250Mhz, memory 750Mhz, underclocked but that has no effect on tearing), driver Cat 8.10 I think.

Attached a madVR OSD data.

When it can run smooth in 24p, I'll give it a serious try!

regards,

Li On
Yup i confirm, had a quick test at 24hz and indeed massive tearing, no prob at 48/50/60.

Vista 32, Nvidia 9400 IGP, Intel 8300 2.83Gh

AERO ON
Playing 1080p/23 at 23.976 refresh rate (no scaling) I have very smooth playback, no tearing at all. Avr and max gpu renderig time are very stable (24/32). OSD stably says disp rate is 23.976.
And subjectivly colors (Pio LX-5090) look more vivid then using EVR CP (autosuggestion? :)). Thanks to madshi for softcubic100 chroma upsampling and direct 16-bit pipeline. :thanks:

AERO OFF
Can not get smooth playback. Gpu rendering time is floating.

[honai]

Those should not change as much (if at all) over lifetime. Which means that with such light sources it might make sense to hire a professional calibrator and calibrate your projector once and for all with the best spectrometer available out there.

Unfortunately it's a death march.

Once you have that part of the equation solved you'll realize that there's something called "radiosity", i.e. the wave length of light is modified when hitting the surface of objects in your room. So unless you are prepared to watch movies in a black matte painted room with no other objects other than the black seat ...

But then, on the other hand, let's also not forget the psychovisual properties of the human eye. Remember the time when we had green CRT displays, and how after some time you started to see actual colors on them? ;) The point here is that even on a 100% sight eye you'll have factors that greatly influence perception: time of day, seasons, blood pressure, illness, etc. and that, still, the "graphics processing unit" of the brain can make up for all of it so that you won't notice the difference because the brain corrects all of it. So even if at one point you have a perfectly calibrated system, colors and luminance on some days might still be off, which leads to the conclusion that the human eye works in the analog, not digital domain and that it is perfectly capable of reconstructing the "real" world from imperfect sources. :)

[tetsuo55]

i think the discussion is getting a little sidetracked here.

madVR can and should give the scientifically and maybe phycovisually best image it can produce.

What humans can and cannot see is all based on average's, plenty of women have a 4th color sensor in their eyes for example.
They're theoretical limit for seeing different colors is so high, it would require something like a 128bit per compononent signal before they stopped seeing the differences

[leeperry]

unless you are prepared to watch movies in a black matte painted room with no other objects other than the black seat ...
don't forget ninja clothing too, it all adds up in the end :D

that's why ANSI contrast doesn't really matter >300, too many room reflections...anyway, yeah we're getting slightly OT

[honai]

The point I was trying to make is that we already have very good color/luminance reproduction with the current means in madVR, and going beyond that you'll end up in esoteric circles (cf. audiophile discussions in other boards where people start putting their loudspeaker cables into the refrigerator before listening sessions).

Instead of trying to achieve the last 0.01% in perfection resources would be better invested in smooth playback. ;)

[leeperry]

Instead of trying to achieve the last 0.01% in perfection resources would be better invested in smooth playback. ;)
that we agree, but madshi does it for free ya know :o
and besides it'd be done through cr3dlut I think..

[madshi]

Instead of trying to achieve the last 0.01% in perfection resources would be better invested in smooth playback. ;)
it'd be done through cr3dlut I think..
That is exactly the point. I'm doing *zero* work on CMS. yesgrey3 is doing all the work. The reason why this whole CMS discussion started was that I did *not* want to do the CMS work myself (via shader math), as requested/suggested by some people, but I want to continue using the 3dlut principle. Which means that I've more resources available for improving other things...

[leeperry]

yesgrey3 is doing all the work.
http://forum-images.hardware.fr/images/perso/indiana%20jones.gif

point taken, looking forward to the smooth releases.

I got 23.976@48Hz working perfectly w/ Reclock(just as smooth as HR)....but as always in MPC it start dropping frames after 1H, all the renderers in MPC do that in non-D3D exclusive mode(reproduced on many different boxes, not just mine) :(

only HR does not...if you catch the VSYNC fliptime properly, which is quite complicated to begin with :o

Beliyaal has found ways to never miss it on XP from what I've seen, so if you could maybe add triple buffering or get some hints from Beliyaal(who spent a long researching this), we might have a winner!

[nijiko]

nijiko, your videocard might be overheating?

Of course not!
And my drivers are usually newest by NVidia.(Now is 185.81.)
And, there is not problem with other renderers, such as haali or EVR (in XP).
Nowaday my video card still can play Need For Speed Undercover and Burnout Paradise very well.
So i don't think it's about videocard.
And at my local, now temp. is 13~25C, so card overheating is not probably.
I consider it's about the compatibility of madVR.
However, it does not perform to every video formats.
But now happens with some special environment(some encoding and decoding method.).
I will try to make dumps to upload.

[madshi]

Of course not!
And my drivers are usually newest by NVidia.(Now is 185.81.)
And, there is not problem with other renderers, such as haali or EVR (in XP).
Nowaday my video card still can play Need For Speed Undercover and Burnout Paradise very well.
So i don't think it's about videocard.
And at my local, now temp. is 13~25C, so card overheating is not probably.
I consider it's about the compatibility of madVR.
Then why are you the only one who has these crashes after 30-45min of playback? Nobody else has reported such a problem yet.

I will try to make dumps to upload.
I have no use for dumps.

[leeperry]

BTW, if that makes any sense I might have some clues as to why any other renderer except HR fails after 45'/1H in MPC on XP(in non-3D exclusive mode), and drops frames like crazy...

HR renders frames ahead and keeps the cache in the graphic card's RAM, doing realtime jitter correction to be damn sure that they're presented right on time.

regular presenters in MPC also cache frames in advance but don't do any jitter correction....they simply present frames and hope for the best, and if some frames are late they will simply be dropped(something HR *never* does, as they're never late to begin with :o )....and if too many frames are late, it will constantly drop, requiring a reseek(Reclock is like an unstoppable train, it won't stop for anything!)

I was told that the only way to avoid this issue on XP w/ EVR/VMR9 was to force exclusive mode...which basically does Aero's job.

right now -as I understand it- mVR does lot of stuff w/ the GPU but still has a regular presenter like EVR/VMR that's vulnerable to VSYNC hiccups....but I'm sure it's in your plans to make a bulletproof presenter :cool:

[6233638]

Finally, I can post after being registered long enough.
Vista 32, Nvidia 9400 IGP, Intel 8300 2.83Gh

AERO ON
Playing 1080p/23 at 23.976 refresh rate (no scaling) I have very smooth playback, no tearing at all. Avr and max gpu renderig time are very stable (24/32). OSD stably says disp rate is 23.976.
And subjectivly colors (Pio LX-5090) look more vivid then using EVR CP (autosuggestion? :)). Thanks to madshi for softcubic100 chroma upsampling and direct 16-bit pipeline. :thanks:

AERO OFF
Can not get smooth playback. Gpu rendering time is floating.
Can I ask what drivers/settings you're using?

I just built myself a new HTPC a few weeks ago—a 2.5GHz Pentium Dual Core with 4gb RAM and Gigabyte's 9400 motherboard and I can't get anything even close to smooth playback when madVR is enabled. My rendering times are 2-3x what yours are.

Even upscaling DVDs (PAL slowed down with ReClock) rather than 1080p playback stutters here. I'm really starting to wish I had gone for a more powerful CPU (I thought the 9400 was supposed to handle everything smoothly) and waited for a 4770 instead. :(


I have to say though, after experimenting with madVR, I'm questioning the benefits of 16-bit rendering. With madshi's test patterns, the benefits are obvious.

With Blu-Ray playback, I am struggling to see any kind of benefit from the 16-bit rendering in actual film content. Scenes that are posterised in Beliyaal's MPC-HC build with EVR Custom are more or less identical in madVR with no improvement. (just very slightly different due to chroma being handled differently)

Are the only real benefits of 16-bit rendering supposed to be for DVD upscaling? (which I haven't compared)


And there was discussion a page or two back about 32-bit or even 64-bit rendering being required for linear light processing. Unless I'm wrong, I think 32-bit would be enough? 256^2.2 = 198,668 steps of gradation, and 32-bit allows for 4,294,967,296 steps of gradation. I'm not sure you would even need to process in 32-bit though. The closest equivalent of the Rec.709 transfer is 1.96 gamma which would require 52,499 shades, and 16-bit allows for 65,536. (I'm not sure how many steps of gradation are required for the exact Rec.709 transfer function rather than the closest match though)

[nlnl]

Finally, I can post after being registered long enough.

Can I ask what drivers/settings you're using?


driver 182.5, 2G RAM, 512M videobuffer, MPC - НС 1079, Haali splitter, Gigabyte mb, no scaling, softcubic100, no 3dlut.
Playback is smooth, but EVR CP is surely smoother (stddev of jitter - 0.005ms).
What display do you use? Does it nativly support 23.976p input?

[yesgrey]

And there was discussion a page or two back about 32-bit or even 64-bit rendering being required for linear light processing. Unless I'm wrong, I think 32-bit would be enough? 256^2.2 = 198,668 steps of gradation, and 32-bit allows for 4,294,967,296 steps of gradation.
I was talking about 32bit FP, which has a mantissa of 24bits. The highest possible gamma value is 2.8, which would need 23bits for its representation. But the problem also comes from the operations with the numbers, which would cause some roundings that could decrease the precision. As I told, 32FP should be good enough, but it could not be enough for keeping the full precision...

[6233638]

driver 182.5, 2G RAM, 512M videobuffer, MPC - НС 1079, Haali splitter, Gigabyte mb, no scaling, softcubic100, no 3dlut.
Playback is smooth, but EVR CP is surely smoother (stddev of jitter - 0.005ms).
What display do you use? Does it nativly support 23.976p input?
I've been outputting to a Sony HW10 via HDMI (reports as 23.977 in reclock) and an old ViewSonic CRT over VGA at 1920x1440@47.952. Can't get smooth playback on either with madVR. (actually, I'm struggling to get proper lip-sync and 100% smooth playback through a whole film without it when playing back blu-ray converted to mkv)

I was talking about 32bit FP, which has a mantissa of 24bits. The highest possible gamma value is 2.8, which would need 23bits for its representation. But the problem also comes from the operations with the numbers, which would cause some roundings that could decrease the precision. As I told, 32FP should be good enough, but it could not be enough for keeping the full precision...
Right, I wasn't sure whether I should jump in as some of the technical details here are a bit over my head.

I thought you only needed that precision when performing the degamma on the video signal (which is always the inverse of the Rec.709 curve with HD content) to get it to linear light for processing and then it was all rounded down to 8/10 bits when gamma encoded for output to the display. (as no graphics cards can output anything higher)

[yesgrey]

I thought you only needed that precision when performing the degamma on the video signal (which is always the inverse of the Rec.709 curve with HD content) to get it to linear light for processing and then it was all rounded down to 8/10 bits when gamma encoded for output to the display. (as no graphics cards can output anything higher)
Yes, but the degamma/engamma with rounding down to 8bits, when using 32FP for processing, does not give always the same numbers that were inputted... some RGB values have an error of +/-1. Not much, but there is an error.

[73ChargerFan]

Then why calibrate at all?
My HP dlp rear-screen is in the living room, which has east facing windows that are always open. As a result, the ambient light levels around the screen vary widely throughout the day.

I can correct this by adjusting the brightness/contrast on the set, but then I have to reset them, which I usually forget.

Is there a theory of how to compensate for ambient light? I'm thinking a cheap light meter hooked up to a usb port, and periodic measurements to auto-adjust the brightness & contrast.

I think this is another facet to the color correction. When I can't see the image, colors don't matter much.

- Anthony

[masaykh]

Little question:
will madvr support subtitle?
in mpc-hc using madvr i dont have subtitile at all :(

[yesgrey]

Little question:
will madvr support subtitle?
Yes.

in mpc-hc using madvr i dont have subtitile at all :(
Use ffdshow.

And next time use search. These questions were already answered several times...;)

[masaykh]

i searched but for "subtitile" not for subs:)

More questions:
i noticed something strange, i have file
Video: DivX 6 640x480 23.98fps 3843Kbps [Video 0]
length 2:38 min
(mpc-hc 1079 \ win xp sp3 \ nvidia 6100 \ 185.81 driver)

if renderer vmr9 - 23.98fps
if haali - 24.05fps
if MadVR - started with 40.88 and droped to 23.99 \ 24.02fps through 1.30 of clip play

is this some bug or is this normal?

all of those renders have default settings

p.s. some result in zoomplayer

[TripleH]

An update:

Last night I decided to give madVR another try, this time using v0.8 and with Aero enabled.

So, with Aero enabled I get a perfect smooth playback at 1080p @ 23.976hz.

The only strange thing is sync issue with reclock, but this is for another thread.

[tetsuo55]

madshi,

Do you have any plans to add something like sony bravia 200hz motionflow?

It basically displays any content at 200hz and interpolates the missing frames.(resulting in added detail in fast movement scenes).

It could help with things like pan's and fast action or sports.

Although i have read some claims of people saying it destroys the film effect, making the image more realistic but in an uncanny valley way.

Obviously if you did have plans for this it would not do 200 but rather interpolate everything to the native refreshrate of the display

[KoD]

Now that nVidia has released official drivers for laptops with video CUDA decoding, I'm finally able to decode all kinds of video on my laptop, the buffers in madVr are never empty, and the rendering times are half of what they used to be. So now I have confirmation that, indeed, stuttering is what one sees when the max gpu rendering time is above the frame duration. When downsizing from 1920x1080 to 1440xsomething I'm able to see this clearly: when I use Lanczos3 for resampling my max gpu rendering times are always below frame rendering times, and playback is perfectly smooth. However, using Lanczos4, my max gpu rendering times are higher than frame duration, and playback is jerky (but buffers are always full, and CPU load is low). Luckily for testing, switching between Lanczos3 and Lanczos4 for downsampling causes this limit behavior so I was able to have confirmation on what I thought was happening.

And now, for a bug (or maybe not) report:
- I guess nobody noticed, while discussing on colorimetry and such, but madVR using 3dlut, and madVR using shaders, give different colors. On my system, I have this very nice video clip, originated from a DVD, with TV colors, and black at 16. When using 3dlut, and asking madVR to output PC levels, that black at 16 is nicely expanded to black at 0 (PC level). However, when I disable 3dlut, and let madVR use shaders, the black is not RGB(0,0,0) anymore, but RGB(1,0,1) or RGB (1,0,0) or RGB (0,0,1), or even RGB(0,0,2) Rounding errors when using shaders ? Or maybe the 3dlut performs gammut mapping from NTSC to sRGB, while the shaders go from NTSC to NTSC ?

[Hypernova]

madshi,

Do you have any plans to add something like sony bravia 200hz motionflow?

It basically displays any content at 200hz and interpolates the missing frames.(resulting in added detail in fast movement scenes).

It could help with things like pan's and fast action or sports.

Although i have read some claims of people saying it destroys the film effect, making the image more realistic but in an uncanny valley way.

Obviously if you did have plans for this it would not do 200 but rather interpolate everything to the native refreshrate of the display

Isn't that he already did it? When I change my monitor refresh rate down to 24 Hz, the playback is smooth regardless of the scaling method I use (and the gpu render time is a lot less than when it's at 60 Hz). So I guess madVR always render at monitor refresh rate? Just my wild guess though.

[Egh]

Hmmmm. Tetsuo55's idea is very interesting. Trouble imho is lack of CPU/GPU power for such task. And of course would require perfect refresh rate detection.

And the issue with vsynс still remains. As typical contemporary display works @60Hz only, the minimum display interval is just over 16ms. With the standard frame rate each frame is to be displayed for nearly 42ms. Imho such upconvert video would be quite ugly.

With higher CRT refresh rate things will be better, as minimum interval is reduced to 10ms (@100Hz) which would allow smoother playback.

I'd suggest first to try with a simplified algorithm. That would also impose lesser requirements for refresh rate detection. Should work quite good imo for 4 intervals rates (85Hz and 100Hz). In this simplified case, each frame is presented as follows: 50%-100%-100%-50% across four vsync intervals. Hopefully would not blur much at all, as half of the time the frames are presented in the natural form.


Isn't that he already did it? When I change my monitor refresh rate down to 24 Hz, the playback is smooth regardless of the scaling method I use (and the gpu render time is a lot less than when it's at 60 Hz). So I guess madVR always render at monitor refresh rate? Just my wild guess though.


It does display @ refresh rate. However it doesn't do any framerate manipulations so far.

[madshi]

Even upscaling DVDs (PAL slowed down with ReClock) rather than 1080p playback stutters here.
The best bet to get rendering times down is to use 1:1 display without any scaling. Upscaling DVDs costs a lot more GPU performance with madVR then displaying 1080p content without any scaling.

I have to say though, after experimenting with madVR, I'm questioning the benefits of 16-bit rendering. With madshi's test patterns, the benefits are obvious.

With Blu-Ray playback, I am struggling to see any kind of benefit from the 16-bit rendering in actual film content. Scenes that are posterised in Beliyaal's MPC-HC build with EVR Custom are more or less identical in madVR with no improvement. (just very slightly different due to chroma being handled differently)

Are the only real benefits of 16-bit rendering supposed to be for DVD upscaling? (which I haven't compared)
madVR contains some small improvements in exactness/quality in different areas. But most of the improvements are only clearly visible in specific scenes. E.g. chroma upsampling improvements are mostly visible in red-on-black scenes. The benefits of 16bit rendering may be even harder to see in real life. The benefits are visible in test patterns and they are there (but hard to see) with real life content, too. In the end if you don't see much of a difference then that shows that EVR-Custom already does a good job. Still, madVR should be the mathematically most exact renderer which exists in the HTPC world. Whether that is worth anything to you or not is up to your personal judgement.

It should also be said that madVR is still in early beta state. It's not feature complete yet. So you can expect further improvements in quality & performance...

I've been outputting to a Sony HW10 via HDMI (reports as 23.977 in reclock) and an old ViewSonic CRT over VGA at 1920x1440@47.952. Can't get smooth playback on either with madVR.
You can check out the GPU rendering times in the OSD (Ctrl+J). As long as the average rendering times are noticeably lower than the movie frame duration time, a future version of madVR should play smoothly on your hardware. Right now madVR is not optimized for smooth playback yet...

i noticed something strange, i have file
Video: DivX 6 640x480 23.98fps 3843Kbps [Video 0]
length 2:38 min
(mpc-hc 1079 \ win xp sp3 \ nvidia 6100 \ 185.81 driver)

if renderer vmr9 - 23.98fps
if haali - 24.05fps
if MadVR - started with 40.88 and droped to 23.99 \ 24.02fps through 1.30 of clip play

is this some bug or is this normal?
Not sure where you got these FPS numbers from. But both Haali and madVR render some frames "on storage" at the beginning of the movie to even out decoding variances. That may explain why the FPS you got reported was higher for Haali and madVR in the beginning of playback.

Do you have any plans to add something like sony bravia 200hz motionflow?
No, these things are extremely hard to do and very calculation intense (if you want to do it right).

now I have confirmation that, indeed, stuttering is what one sees when the max gpu rendering time is above the frame duration.
With the current madVR version that's correct, because madVR currently renders a frame, then waits for VSync and only after the VSync occured, starts rendering the next frame. Obviously that's very suboptimal. With a future madVR version, things will change quite a lot in this area and max gpu rendering times will hopefully lose most of their meaning. Average gpu rendering times is what counts in the long run...

And now, for a bug (or maybe not) report:
- I guess nobody noticed, while discussing on colorimetry and such, but madVR using 3dlut, and madVR using shaders, give different colors. On my system, I have this very nice video clip, originated from a DVD, with TV colors, and black at 16. When using 3dlut, and asking madVR to output PC levels, that black at 16 is nicely expanded to black at 0 (PC level). However, when I disable 3dlut, and let madVR use shaders, the black is not RGB(0,0,0) anymore, but RGB(1,0,1) or RGB (1,0,0) or RGB (0,0,1), or even RGB(0,0,2)
If you shoot the same picture twice, it will be different each time, due to dithering. You can turn off dithering to get "static" results. But results like RGB(0,0,2) shouldn't be caused by dithering. So I guess there's a problem somewhere. Can I get a small sample with which I can reproduce the problem, please?

[cyberbeing]

madshi, have you had any luck figuring out how to fix the rendering time spike with that sample I posted a week ago?

[yesgrey]

Do you have any plans to add something like sony bravia 200hz motionflow?
No, these things are extremely hard to do and very calculation intense (if you want to do it right).
I agree. But what about something like the black frame insertion? That should not be very gpu intensive, and some users report it to look good with some source material... I was considering trying something using avisynth, but in madVr it could be a lot easier and faster.

[honai]

Black frame insertion only has benefits at high refresh rates (> 100 Hz) and increases the perceived contrast, i.e. it's a psychovisual trick. I'm not sure if there are any LCD devices out there which accept refresh rates higher than 72 Hz at 1080p.

[Egh]

Black frame insertion only has benefits at high refresh rates (> 100 Hz) and increases the perceived contrast, i.e. it's a psychovisual trick. I'm not sure if there are any LCD devices out there which accept refresh rates higher than 72 Hz at 1080p.

They are. cyberglasses require high refresh rates, iirc there were some models specifically for that with 120Hz rates.


Black frame insertion only has benefits at high refresh rates (> 100 Hz) and increases the perceived contrast, i.e. it's a psychovisual trick.


How does it do that? And how often to insert black frames? With 100Hz CRTs it might be worth to implement this as a possible mode in madVR. Proud CRT owners like me then might be happy ;) Subject to no flickering of course.

My algorithm is still though the best amongst suggested, and computationally very efficient.

[Hypernova]

I have to say though, after experimenting with madVR, I'm questioning the benefits of 16-bit rendering. With madshi's test patterns, the benefits are obvious.


I want to add that if you watch anime like me, the benefit of madVR is sometimes so obvious that doesn't need special attention to detect. The easiest one is color band. While you can use ffdshow's deband/gradfun to get rid of the problem, madVR by itself produce a better result compare to EVR CP that even video quality idiot like me can see.

[leeperry]

I was considering trying something using avisynth, but in madVr it could be a lot easier and faster.
processing 120fps in AVS will take some crazy CPU I think :D
there was a thread here : http://forum.doom9.org/showthread.php?t=144276

[6233638]

I've done more testing, and I was definitely mistaken about madVR's use with actual video content.

The problem is that I was looking for the elimination of posterisation rather than a slight reduction of it, and I wasn't comparing frame grabs, but playing the same scenes over and over again.

Strangely, the differences seem much more apparent on my laptop's LCD rather than on my CRT. (not tried the HW10)

An out of focus Jude Law from Breaking and Entering, 1:03:18.

8-bit VC-1 DXVA in Beliyaal's MPC-HC Build:
http://img91.imageshack.us/img91/1928/8bit.th.png (http://img91.imageshack.us/img91/1928/8bit.png)

10-bit VC-1 DXVA in Beliyaal's MPC-HC Build:
http://img148.imageshack.us/img148/6051/10bit.th.png (http://img148.imageshack.us/img148/6051/10bit.png)

ffdshow in Beliyaal's MPC-HC Build:
http://img60.imageshack.us/img60/50/ffdshow.th.png (http://img60.imageshack.us/img60/50/ffdshow.png)

madVR w/ffdshow in Beliyaal's MPC-HC Build:
http://img359.imageshack.us/img359/7114/madvr.th.png (http://img359.imageshack.us/img359/7114/madvr.png)


I'm not sure if that means madVR's 16-bit rendering isn't enough yet, or if that's what's on the disc and it can't be improved any further.

[madshi]

madshi, have you had any luck figuring out how to fix the rendering time spike with that sample I posted a week ago?
I've downloaded it, but not analyzed yet.

I want to add that if you watch anime like me, the benefit of madVR is sometimes so obvious that doesn't need special attention to detect. The easiest one is color band. While you can use ffdshow's deband/gradfun to get rid of the problem, madVR by itself produce a better result compare to EVR CP that even video quality idiot like me can see.
Sometimes these banding artifacts are more visible in motion, so it can be difficult catching it in screenshots. But if you find cases where you can see a very noticeable difference in screenshots, I'd be happy to see some examples!

I've done more testing, and I was definitely mistaken about madVR's use with actual video content.

The problem is that I was looking for the elimination of posterisation rather than a slight reduction of it, and I wasn't comparing frame grabs, but playing the same scenes over and over again.
Thanks, these are good screenshots! Finally some real world screenshots where the benefits of 16bit show (albeit only slightly).

madVR does not eliminate posterisation, it does not even reduce it. madVR just displays the original content as exact as possible. While other renderers round down to 8bit, which can create posterisation or increase already existing posterisation.

If you see posterisation with madVR then you can be sure it's on the disc.

BTW, the 10bit EVR-Custom screenshot is not helpful because the screenshot itself is only 8bit. You will have to compare directly in the media player on screen to check whether 10bit EVR-Custom shows an improvement over 8bit.

[Hypernova]

As you wish, Madshi :) I might exaggerate it though... and I hope these screenshot won't get me into some troubles...

http://img520.imageshack.us/img520/3310/evrcp.th.jpg (http://img520.imageshack.us/img520/3310/evrcp.jpg)
http://img520.imageshack.us/img520/8082/madvr.th.jpg (http://img520.imageshack.us/img520/8082/madvr.jpg)

Look at the band at the grey area on the bottom right corner. I think it's easily noticable. I know it's not exactly the same frame (I learn how to do that right after I take the shots and too lazy to do it again) but it should not matter much.

Edit: If you worry about jpeg's artifact, I can confirm that's not the case. It is what I really see (and both are jpeg anyway).

[KoD]

PM with sample sent.

[6233638]

BTW, the 10bit EVR-Custom screenshot is not helpful because the screenshot itself is only 8bit. You will have to compare directly in the media player on screen to check whether 10bit EVR-Custom shows an improvement over 8bit.
Oh right, I thought it was just rendering in 10-bit and always ended up as 8-bit for output from a PC no matter what. (I just got started on HTPCs a few weeks ago really)


Do you think that using more bits for processing (32/64-bit FP) and/or linear processing would improve things at all, or is madVR currently as good as it'll get as far as posterisation is concerned?

Would enabling the 10-bit output have any effect on the image at the display when madVR is used?

[madshi]

Look at the band at the grey area on the bottom right corner. I think it's easily noticable. I know it's not exactly the same frame (I learn how to do that right after I take the shots and too lazy to do it again) but it should not matter much.
Nice - thanks!

This is with quite a high upscaling factor. Is the visible difference equally big without scaling? Or is it bigger when you upscale that much?

Would be nice to have screenshots of exactly the same frame. With madVR you can't frame step right now. But you can do so with EVR. So you can do this: (1) do a screenshot with madVR. (2) pause EVR playback a second (or so) before the madVR screenshot. Then in MPC HC use the right arrow key to step through the frames until the frames match 100%.

You may want to try IrfanView's PNGOUT plugin. It creates lossless PNG files with good compression. Of course compression is not as high as jpeg, but it's the best I've seen for lossless compression.