madVR - high quality video renderer (GPU assisted)

[Neeto]

That's not a bug in madVR. The filter which delivers the data and information to madVR is claiming the video is 25.000 fps. It's not something madVR invented for itself. madVR is being *told* that the video file is 25.000 fps. If you want to find out who is responsible for this error, you can in MPC-HC right click the properties of every loaded filter, then lock at the "Pin Info" tab. Write down the value "AvgTimePerFrame" for all filters and post it here.

Did some more digging on this as I found some changes in behaviour.
I tried PVD10 and it shows "unknow frame rate" in madVR rather than the 25 fps.
Found out I needed to look at both the Pin In and Pin Out info.
When I use ffdshow I get the following Pint Out info.
Note the changes in the "AvgTimePerFrame".
It seems MadVR is using the first one (AvgTimePerFrame: 400000) & ignoring the others, even though it's using one of the connections with the AvgTimePerFrame: 333666

Filter : ffdshow Video Decoder - CLSID : {04FE9017-F873-410E-871E-AB91661A4EF7}

- Connected to:

CLSID: {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
Filter: madVR Renderer
Pin: Input

- Connection media type:

Video: YV12 1024x480 (4:3) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(704,480)
rcTarget: (0,0)-(704,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 4
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 737280
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 c0 02 00 00 e0 01 00 00 ........À...à...
0010: 00 00 00 00 00 00 00 00 c0 02 00 00 e0 01 00 00 ........À...à...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 00 00 00 00 00 00 00 00 04 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 04 00 00 ........(.......
0050: 20 fe ff ff 01 00 0c 00 59 56 31 32 00 40 0b 00 þÿÿ....YV12.@..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

- Enumerated media type 0:

Video: YV12 704x480 (4:3) 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 506880
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(704,480)
rcTarget: (0,0)-(704,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 4
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 704
biHeight: 480
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 506880
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 c0 02 00 00 e0 01 00 00 ........À...à...
0010: 00 00 00 00 00 00 00 00 c0 02 00 00 e0 01 00 00 ........À...à...
0020: 00 00 00 00 00 00 00 00 62 17 05 00 00 00 00 00 ........b.......
0030: 00 00 00 00 00 00 00 00 04 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 c0 02 00 00 ........(...À...
0050: e0 01 00 00 03 00 0c 00 59 56 31 32 00 bc 07 00 à.......YV12.¼..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

- Enumerated media type 1:

Video: YV12 704x480 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 506880
cbFormat: 88

VIDEOINFOHEADER:
rcSource: (0,0)-(704,480)
rcTarget: (0,0)-(704,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333666

BITMAPINFOHEADER:
biSize: 40
biWidth: 704
biHeight: 480
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 506880
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 c0 02 00 00 e0 01 00 00 ........À...à...
0010: 00 00 00 00 00 00 00 00 c0 02 00 00 e0 01 00 00 ........À...à...
0020: 00 00 00 00 00 00 00 00 62 17 05 00 00 00 00 00 ........b.......
0030: 28 00 00 00 c0 02 00 00 e0 01 00 00 03 00 0c 00 (...À...à.......
0040: 59 56 31 32 00 bc 07 00 00 00 00 00 00 00 00 00 YV12.¼..........
0050: 00 00 00 00 00 00 00 00

[fps]

what does "better rendering times" imply on the screen ?
It means that you can possibly use "a more demanding" scaling algorithmus compared to what you are able to use in windowed mode. That is more relevant to "weak GPUs" though, e.g. integrated graphic solutions, with a standalone GPU of the $50 dollar range you should be pretty much able to use any scaling algorithm.

[/noah/]

It means that you can possibly use "a more demanding" scaling algorithmus compared to what you are able to use in windowed mode. That is more relevant to "weak GPUs" though, e.g. integrated graphic solutions, with a standalone GPU of the $50 dollar range you should be pretty much able to use any scaling algorithm.

OK, thanks a lot.

[webs0r]

Yes, basically you display a few test patterns (showing specific colors), measure them with a meter, and then provide the measurement results to yCMS. yCMS will then calculate a "correction" file, called "3dlut", which madVR will then use to improve output quality.

madVR adjusts the output color depending on the source content in any case, even if you don't use yCMS. The purpose of yCMS is to repair anything which might be wrong with your display (and which can technically be repaired by software).

Thanks madshi!!

I went and got a meter (i1 display2) and calibrated my gaming monitor, laptop monitor and then moved onto the TV. I've managed to get the TV gamut nearly spot onto the HD gamut thanks to its wealth of colour controls (color space/white bal)!

Would madVR+yCMS offer further benefits even though the gamut triangle seems very well mapped?

[e-t172]

If i want to properly measure my display, should i use madVR running test pattern files, or preferably rather the HCFR internal patterns?
I would've thought using madVR to render the test pattern would be preferable so i already have my target environment, however i'm now unsure if madVR not already modifys the colors of the test files and throws off the measurements.

It depends. If you want to calibrate your display (using its hardware controls), it is more convenient to do so using HCFR's patterns. If you want to generate a 3dlut, then you should calibrate using madVR as it is the closest you can get to the final chain (because, well, it IS the final chain). Also, using madVR is the only way to ensure you did everything correctly, since you need to measure with the 3dlut applied which only madVR can do.

[HTPC-User]

Hi!

hello, strange enough, i have the exact opposite issue, but i did not notice it was content fps related... Have you tried pal dvds or HD contents to check wether the switch was content related or not ? What is your graphic card ?

Well, perhaps it makes sense to describe my config in detail:
Normally I watch 50Hz content, so my primary display (the TV) is set to 50Hz. The second display, a touchscreen, is deactivated in Catalyst Center (11.1), so only the TV is active in this scenario.

If the TV is set to 50Hz and I watch 50Hz content no display change -> ok
If the TV is set to 50Hz and I play 60Hz content no display change -> ok, as automatic display change is disabled (line is empty).
If the TV is set to 60Hz and I play 50Hz content madVR changes to 50Hz -> not ok, display change is disabled.
And if the TV is set to 60Hz by me and watching 60Hz content madVR changes to 50Hz -> also not ok.

The whole time the second VGA (touch) monitor is disabled in CCC so that should not the cause for this behavior.

Perhaps madshi can comment on this and what we can try next.

Meanhile I've got some questions:
1.) Where can I modify the target scaling dimensions in order to maintain the aspect ratio? What I mean is this: What happens when playing back content with a aspect ratio that doesn't match the screen AR? Normally you got eggheads, so until now I resolved this problem in the resizing tab of ffdshow. But with madVR?

2.) Using a projector the madVR`s osd text is mainly green, but some pixels are grey. Is this a bug in the ATI driver, a configuration problem or some problem within the projector? According to various sources the projector is capable of full rgb 4:4:4, so the CCC is set to full RGB 4:4:4.
(My TV is not a full HD one, so I can't easily compare the osd on both.)

:thanks:

[nevcairiel]

It depends. If you want to calibrate your display (using its hardware controls), it is more convenient to do so using HCFR's patterns. If you want to generate a 3dlut, then you should calibrate using madVR as it is the closest you can get to the final chain (because, well, it IS the final chain). Also, using madVR is the only way to ensure you did everything correctly, since you need to measure with the 3dlut applied which only madVR can do.

I figured for a final measurement after 3dlut i would of course do it with madVR to confirm the results, but before .. if madVR changes the color of the test pattern, because i told it my TV is Rec. 709, doesn't that add an artificial error into the test?
Those adjustments won't be performed when i have a 3dlut running (because the 3dlut specifys how my display is calibrated), so i would have to measure my TV without any color correction on the renderers side, i figure.

[e-t172]

I figured for a final measurement after 3dlut i would of course do it with madVR to confirm the results, but before .. if madVR changes the color of the test pattern, because i told it my TV is Rec. 709, doesn't that add an artificial error into the test?
Those adjustments won't be performed when i have a 3dlut running (because the 3dlut specifys how my display is calibrated), so i would have to measure my TV without any color correction on the renderers side, i figure.

You're thinking about it backwards. When you're generating a 3dlut, you're generating it for the whole video playback chain, including madVR and the "color correction" it's already doing.

Think about it this way: if you're calibrating outside madVR, then you got a 3dlut suitable for use outside madVR. If you're using this 3dlut inside madVR, and madVR is applying its own "color correction" on top of it, then the final result will be off, because this "color correction" was not taken into account when the calibration was done.

[nevcairiel]

You're thinking about it backwards. When you're generating a 3dlut, you're generating it for the whole video playback chain, including madVR and the "color correction" its already doing.

I don't think so. Right now its configured to assume my TV is a perfect Rec 709 display, so it changes all colors to match that, but if i add a 3DLUT, it knows exactly how the display is showing the colors, and all color correction is then done by the 3DLUT, the previous correction to match a Rec. 709 display is no longer applied.
Somehow it makes sense to me to measure the colors without any correction, because the 3DLUT is applied without any previous correction.

[/noah/]

Hi!
1.) Where can I modify the target scaling dimensions in order to maintain the aspect ratio? What I mean is this: What happens when playing back content with a aspect ratio that doesn't match the screen AR? Normally you got eggheads, so until now I resolved this problem in the resizing tab of ffdshow. But with madVR?

If you're using MPC HC, you scan simply specify the correct ratio, when playing the movie : right click/aspect ratio.

On my side, i will try to play various fps movies, to check if my problem is also content dependent.

[e-t172]

if i add a 3DLUT, it knows exactly how the display is showing the colors, and all color correction is then done by the 3DLUT, the previous correction to match a Rec. 709 display is no longer applied.

Oh, I didn't know that. I thought madVR always applied gamut correction even if a 3dlut is in use. If that's not the case, then you're right, of course.

[peckec]

Did upgrade from 0.61 to 0.65.
Maybe this is already known, but it seems that there is a bug with display changer.
I have following modes configured: 1080p24, 1080p50, 1080p59, 1080p60
Now when playing 23.976p content it switches somehow to 1080p59 instead of 1080p24.
I'm using ReClock to sync fps exactly to 24.
Using 0.61 it works perfectly.

[Skwelcha]

@peckec, at first i had a similiar problem when i tried various settings in the display changer, at one point all i got was 59hz. I deleted all values, restarted madvr, changed the current display refreshrate for windows to 60hz and typed in the values again, after that all went correct again.

[leeperry]

just wanted to say that I've subjectively compared the dithering of:
-0.49
-0.62 using 7/8/9/10bit
-0.65

and the latter is the clear winner to me on my CRT(using SmoothL() as well), way to go madshi! it's amazing how a proper dithering seems to increase the clarity of the picture and the "pop" effect. I was mostly using a scene in a train from "The Good, the Bad, the Weird", it's a fast camera movement in third person view and there's a zillion details in the train cabins..It looks absolutely amazing w/ 0.65 /o/

I'll stop nagging you with colorimetry issues(and I sincerely apologize for my foul mouthing in the past), as upscaled SD will always be a problem...and everyone's got his own beliefs when it comes to gamuts. But major kudos about the sharpness and smoothness of madVR :eek: It's about time you'd setup a "donate" button somewhere.

Tritical is working on a CUDA version of ddcc() (http://forum.doom9.org/showpost.php?p=1508047&postcount=673), so that'll allow me to set all kinds of automatic rules in ffdshow depending on the native resolution and frame rate...and stop using ColorMatrix() for upscaled SD as well, so that's good. Alternatives never hurt :cool:

[madshi]

I have some problem with madVR .
1. The value of dropped frames and delayed frames will increase after Windows auto-turn into screensaver or press Win+L by myself. The only way to stop it is to reopen MPC-HC.
The latest version is supposed to pause playback when you press Win+L. Does that not work?

2. Is there an OSD to show time message(like "00:01:09 / 01:45:09" on windows mode) on exclusive mode when I click seek bar?
I think MPC-HC has a keyboard shortcut for that, not sure.

After playing around with the ffdshow output/rgb conversion tab and different settings for TV/PC levels I come to the conclusion that it doesn't matter for madVR which rgb conversion settings are active in ffdshow. Am I right?
So the only setting which has to be identical/match is the PC/TV level setting in the graphics card driver and in madVR. Am I right?
I'm not an ffdshow expert, but I think the level settings only apply if you output RGB from ffdshow.

But now I encounterd a weird behaviour:
My TV is set to 60Hz. But if I play a 60Hz clip (exclusive mode) madVR switches to 50Hz even if the TV is already set to 60Hz manually by me.
The display switch line is empty (I mean the resolution line 1080p25 etc), so automatic display change should be off.
Seems to be a bug as older madVR versions with the automatic change feature didn't show this if I remember me correctly. Or am I doing something wrong?
I don't think older versions behaved differently. But you can try properly filling the display switch line. Maybe that fixes the problem?

By the way, which naming convention has to be fulfilled to get the display changer working? Where do I have to define this modes to recall them via madVR?
Not sure I understand your question. Tell me which modes you want madVR to use and I can tell you what to enter there.

If i want to properly measure my display, should i use madVR running test pattern files, or preferably rather the HCFR internal patterns?
I would've thought using madVR to render the test pattern would be preferable so i already have my target environment, however i'm now unsure if madVR not already modifys the colors of the test files and throws off the measurements.
I'd suggest to use a HD test pattern and play it with madVR. The default decoding (BT.709 decoding, BT.709 primaries) for HD test patterns matches the default display setup (BT.709 primaries), so madVR doesn't have to do any modifications. To be honest, I'm not sure what should ideally happen if you play SD test patterns. Not sure whether madVR should correct the gamut for them or rather not. Maybe yesgrey or leeperry can answer that? I can't...

BTW, I'd delay calibration until the next madVR + yCMS version comes out. Both yesgrey and I have already fixed a couple of bugs, still working on getting accuracy up to scratch.

Did some more digging on this as I found some changes in behaviour.
I tried PVD10 and it shows "unknow frame rate" in madVR rather than the 25 fps.
Found out I needed to look at both the Pin In and Pin Out info.
When I use ffdshow I get the following Pint Out info.
Note the changes in the "AvgTimePerFrame".
It seems MadVR is using the first one (AvgTimePerFrame: 400000) & ignoring the others, even though it's using one of the connections with the AvgTimePerFrame: 333666
madVR uses the pin info it is given. The others from your list are alternatives, but not the "active" one. Since the active one is 400000 that's what madVR uses.

I went and got a meter (i1 display2) and calibrated my gaming monitor, laptop monitor and then moved onto the TV. I've managed to get the TV gamut nearly spot onto the HD gamut thanks to its wealth of colour controls (color space/white bal)!

Would madVR+yCMS offer further benefits even though the gamut triangle seems very well mapped?
If you got the gamut spot on then madVR + the current yCMS version will likely not improve things much for the colors. However, it might be worth it to measure your grayscale and let yCMS improve that. However, I'd wait for the next madVR + yCMS versions for that because there's a bug in the current versions.

Normally I watch 50Hz content, so my primary display (the TV) is set to 50Hz. The second display, a touchscreen, is deactivated in Catalyst Center (11.1), so only the TV is active in this scenario.

If the TV is set to 50Hz and I watch 50Hz content no display change -> ok
If the TV is set to 50Hz and I play 60Hz content no display change -> ok, as automatic display change is disabled (line is empty).
If the TV is set to 60Hz and I play 50Hz content madVR changes to 50Hz -> not ok, display change is disabled.
And if the TV is set to 60Hz by me and watching 60Hz content madVR changes to 50Hz -> also not ok.
If you disable the display mode changing then madVR does not change the display mode. However, Direct3D likes to switch display modes whenever it feels like it. The best way to stop this is to actually tell madVR to take control over the display modes, I believe.

1.) Where can I modify the target scaling dimensions in order to maintain the aspect ratio? What I mean is this: What happens when playing back content with a aspect ratio that doesn't match the screen AR? Normally you got eggheads, so until now I resolved this problem in the resizing tab of ffdshow. But with madVR?
Scaling and aspect ratio are controlled by the media player. madVR provides the media player with a "I'd like this" information, but the media player decides. E.g. when using MPC-HC, right click on the video, then under "Video Frame" toggle between the various options. E.g. try "normal size".

2.) Using a projector the madVR`s osd text is mainly green, but some pixels are grey. Is this a bug in the ATI driver, a configuration problem or some problem within the projector?
The OSD is drawn half transparent, so the colors of the background are shining through. That may make some pixels appear grey. This can happen if the background is mostly blue and red, because green + blue + red = grey.

if madVR changes the color of the test pattern, because i told it my TV is Rec. 709, doesn't that add an artificial error into the test?
Not if the test pattern is already REC. 709 itself... :) Just use a 720p or 1080i/p test pattern, problem solved.

Oh, I didn't know that. I thought madVR always applied gamut correction even if a 3dlut is in use. If that's not the case, then you're right, of course.
When a 3dlut is used, madVR converts the gamut to yRGB, and then the 3dlut converts yRGB to the measured display primaries. That's a whole different processing chain compared to not using a 3dlut.

Did upgrade from 0.61 to 0.65.
Maybe this is already known, but it seems that there is a bug with display changer.
I have following modes configured: 1080p24, 1080p50, 1080p59, 1080p60
Now when playing 23.976p content it switches somehow to 1080p59 instead of 1080p24.
I'm using ReClock to sync fps exactly to 24.
Using 0.61 it works perfectly.
Hmmmm... Just imagine you didn't have Reclock. Wouldn't in that case 1080p59 be better than 1080p24? That's how madVR thinks. Older madVR versions behaved differently due to a bug. I understand, though, that due to Reclock 1080p24 is preferred over 1080p59. BTW, why don't you have 1080p23 in that list? That would be the best way out.

I'll stop nagging you with colorimetry issues(and I sincerely apologize for my foul mouthing in the past), as upscaled SD will always be a problem...and everyone's got his own beliefs when it comes to gamuts.
Apology accepted.

just wanted to say that I've subjectively compared the dithering of:
-0.49
-0.62 using 7/8/9/10bit
-0.65

and the latter is the clear winner to me on my CRT(using SmoothL() as well), way to go madshi! it's amazing how a proper dithering seems to increase the clarity of the picture and the "pop" effect. I was mostly using a scene in a train from "The Good, the Bad, the Weird", it's a fast camera movement in third person view and there's a zillion details in the train cabins..It looks absolutely amazing w/ 0.65 /o/
Glad you like it. It's still simple random dithering, though, not error diffusion. So further improvement via Cuda/OpenCL is still possible. JFMI, are you using 6, 7 or 8 bits with 0.65?

[yesgrey]

To be honest, I'm not sure what should ideally happen if you play SD test patterns. Not sure whether madVR should correct the gamut for them or rather not.
A test pattern for measuring the primaries would not need any correction. Ideally the primaries would be measured using pure RGB images, and not the ones from YCbCr test patterns converted to RGB, like the ones we find on Blu-ray or DVDs, because the latter, when converted to RGB, might not result in exact RGB values.

[leeperry]

Glad you like it. It's still simple random dithering, though, not error diffusion. So further improvement via Cuda/OpenCL is still possible. JFMI, are you using 6, 7 or 8 bits with 0.65?
To be perfectly clear, that's the sample I used: http://www.mediafire.com/?85bcg8vqbiig6e6

When I went from mVR 0.49+SmoothL 1.7 to mVR 0.49+SmoothL 2.0, the PQ improvement was drastic in this scene :eek:

All those ppl in the train seemed to pop out of the screen(thanks to the infinite native contrast ratio of my calibrated flat CRT), amazing! It's also thanks to LSF that sharpens up the motion blur. And going mVR 0.65/8bit+SmoothL 2.0 went another step ahead, yay! I wonder if/when that will ever stop :D

from the changelog, I was under the impression that 0.62 and 0.65 were using the very same dithering code? but I still preferred 0.65 in 8bit over anything in 0.62.

I've tried again to compare 6/7/8bit in 0.65, but it's the same as w/ 0.62, 6/7bit look too "flat"...the picture is not as clear as w/ 8bit. The hero's back looks almost 3D in 8bit, the reflections on his coat are clearer and that woman in the back can clearly be seen as soon as she appears in the picture. Less noisy I would say.

I don't really know what dithering algorithm SmoothL() uses, but I believe you more or less deducted it from some screenshots I sent you a while ago(but that was w/ the old 1.7 version, though). Anyway, both mVR/SmoothL dithering codes together look amazing to me(my CRT uses 10bit VGA, w/ a 10bit CLUT from ARGYLL on top)...and I'd really love to see more dithering algorithms and more options(shape/size?) in mVR to play around w/ if/when any possible.

I will soon be outputting RGB32 to madVR(that's mandatory when using ddcc for gamut mapping), will that be as bad as it sounds? I currently use LSF in SuperSampling mode so it goes like: major uspcale(Spline for luma/Bicubic 0.0 for chroma) > Avisynth scripts(using ColorMatrix for upscaled SD to map the 601 coeffs to 709) > YV12 to madVR > downscale using the GPU(LSF looks jaggy in 1:1, so it's better to use SuperSampling). So I guess all that resizing and 8bit processing more or less kills the whole point of outputting YV12 to mVR in the first place? And going RGB32 will allow me to ditch ColorMatrix and output proper 601 RGB for upscaled SD...that cannot hurt.

I remember you saying that RGB32 didn't remain untouched in mVR, so I guess I'll still benefit a bit from whatever it is that mVR does better than the other VR's :p

[cyberbeing]

leeperry, just remember when designing your scripts that the current version of madVR requires TV levels (16-235/16-240) as input for both Y'CbCr and RGB.
In other words, don't use SmoothL to expand levels from TV to PC with madVR 0.62+, until madshi adds support for 0-255 input.

[leeperry]

leeperry, just remember when designing your scripts that the current version of madVR requires TV levels (16-235/16-240) as input for both Y'CbCr and RGB.
In other words, don't use SmoothL to expand levels from TV to PC with madVR 0.62+, until madshi adds support for 0-255 input.
only when using the LUT's from what I understood?!

I do feed 0-255, whatever as YV12..or as RGB32 tomorrow when I'll be testing the new CUDA version of ddcc() (https://forum.doom9.org/showpost.php?p=1508124&postcount=675) . I've disabled all gamut/gamma tweaks and the TV>PC conversion in mVR.

I don't have crushed blacks or burned whites, but OK I'll run some test patterns. It doesn't seem to mess w/ the BTB/WTW as far as I can tell :confused:

[cyberbeing]

only when using the LUT's from what I understood?!
Here was the last I heard on the subject:
I'm still a bit confused how madVR is dealing with 16-235 input vs 0-255 input. Can you explain? How does madVR processing of 16-235 YUV input differ from 0-255 YUV input? How does madVR processing of 16-235 RGB input differ from 0-255 RGB input?madVR doesn't deal with it at all at the moment. madVR strictly expects all input content to be "video levels". Yes, that's not good and I need to fix that. But there are a million other things I need to do, too, and since PC levels content is very rare, it's not top of my priority. I will support PC levels content sooner or later, though.
I'm not really sure, I was asking about madVR in general in the above, but it's possible he assumed I was only curious about 3dlut behavior. madshi will need to clarify.

[leeperry]

humm, strange results:

0-255 YV12 0.49: http://thumbnails34.imagebam.com/13665/40f9cb136646285.jpg (http://www.imagebam.com/image/40f9cb136646285)
0-255 YV12 0.62: http://thumbnails35.imagebam.com/13665/f0a39e136646288.jpg (http://www.imagebam.com/image/f0a39e136646288)
0-255 YV12 0.65: http://thumbnails39.imagebam.com/13665/b9494e136646289.jpg (http://www.imagebam.com/image/b9494e136646289)
0-255 RGB32HQ 0.62: http://thumbnails45.imagebam.com/13665/713e00136646290.jpg (http://www.imagebam.com/image/713e00136646290)
0-255 RGB32HQ 0.65: http://thumbnails37.imagebam.com/13665/b5362e136646292.jpg (http://www.imagebam.com/image/b5362e136646292)
0-255 RGB32HQ HR: http://thumbnails30.imagebam.com/13665/735e15136646293.jpg (http://www.imagebam.com/image/735e15136646293)

usually RGB32HQ can be used as a hard reference, I might actually find the picture a tiny bit too dark in mVR when using YV12 now that I get to think of it(My CRT has been calibrated using a 2.5 gamma) :o

It's 3:30AM, I'm too tired to troubleshoot...tomorrow's another day, and I need RGB32 to use the CUDA version of ddcc() anyway.

[xvidivx]

The latest version is supposed to pause playback when you press Win+L. Does that not work?

It works fine. MadVR 6.5 will pause when I press Win+L, but after I login to Windows and continue to play, it become seriously dropping. This phenomenon also can be found in earlier version, not only 6.5.


I think MPC-HC has a keyboard shortcut for that, not sure.

The time message appear on VMR-9(renderless) when fullscreen, but it disappear on madvr exclusive mode.

Thanks a lot.:)

--
MPC-HC 1.5.2.3225 + madvr 6.5

[cyberbeing]

@leeperry

That is strange. HR RGBHQ vs 0.65 RGBHQ are identical (dithering aside). 0.49 YV12 vs 0.62 YV12 vs 0.65 YV12 are identical (dithering aside). 0.62/0.65 RGBHQ vs 0.62/0.65 YV12 has a large difference.

Did the shaders in 0.49 also assume 16-235 input? leeperry, when you wake up, can you do another test in 0.49 with the following "HD - PC.3dlut" and output set to PC levels in madVR to see if that changes things?
Input_Format HD YCbCr 8
Input_Range 0 255
Output_Format HD RGB_PC 16

madshi, could you take another go at explaining how 0-255 input is handled in madVR compared to 16-235 input? From leeperry's results, it does appear 0-255 RGB is handled correctly, but 0-255 YV12 isn't? How is it working with 0-255 RGB, if you aren't supporting it? Does this mean 16-235 RGB is left untouched, even when set to output 0-255?

[leeperry]

Well, I haven't used 3DLUT's in mVR in over a year(my CRT is pretty much bang-on SMPTE-C)...I'm seeking a simple, fast and efficient solution for gamut mapping(such as this script (http://www.pixelz.fr/2/a/4/d85e01c507d226af2cbe98e18b6a1.png)) but madshi has made it clear that he wants to stick to 3DLUT's and not provide support for this long time tested and highly effective PS script(my displays are perfectly calibrated, they really only require gamut mapping).

And tbh, it makes far more sense to map gamuts from within ffdshow(so you can set automatic rules depending on the frame rate(23.976/29.97=SMPTE-C/25=EBU) and the original frame size(HD+29.97=HDTV/SD+29.97=SMPTE-C) IMHO(you can of course manually override those rules in a few clicks). Plus there's no loading time as ddcc() doesn't use LUT's, and the VR has no clue as to whether HD content is genuine or upscaled SD from ffdshow. So that's another problem that can't be solved atm.

The LUT idea originally came from the fact that ddcc() is quite a CPU hog, but the new CUDA build fixes this problem altogether. It basically does the same as the MPC-HC script(gamut mapping is a very trivial thing to do via PS), but can automated via ffdshow...so that basically kills all the birds at once :devil:

Long story short, It'd be better if you tried, here's the test pattern(kindly encoded by Kazuya) I used: rec709.mkv (http://www.mediafire.com/?sfd13vqrgn7vh6i)

I'll check my settings, but it would very much appear that the gamma is darkened when feeding PC range YV12 to mVR. Now that you mention it, I remember madshi stating that the luminance data would be at risk when feeding PC range to >0.62, but it'd seem to also be the case w/ 0.49 :o

[Neeto]

madVR uses the pin info it is given. The others from your list are alternatives, but not the "active" one. Since the active one is 400000 that's what madVR uses.


Some more digging around shows that if I uncheck the "DVD decoding" check box in ffdshow Codes tab against MPEG2, then fddshow correctly sets the PIN info to 29.97.

I've reported this as a bug over on ffdshow tryouts.

Still not sure why ffdshow outputs 1024x420 nor why MadVR chooes to connect to it when other options are closer to the the actual media.
I'm also confused why MadVR shows the movie resolution as 704, 480 yet the PIN info says 1024x480.
- Connection media type:
Video: YV12 1024x480 (4:3) 25.00fps
AvgTimePerFrame: 400000
- Enumerated media type 0:
Video: YV12 704x480 (4:3) 29.97fps
AvgTimePerFrame: 333666
- Enumerated media type 1:
Video: YV12 704x480 29.97fps
AvgTimePerFrame: 333666

[nevcairiel]

Still not sure why ffdshow outputs 1024x420 nor why MadVR chooes to connect to it when other options are closer to the the actual media.


madVR requests a certain stride of the image, which means the video decoder is asked to actually produce a image 1024 pixels wide, but only with 704 pixels of actual image. This is usually done to ensure that optimized algorithms that only work on a certain amount of pixels at one time can do their job properly.

For the frame rate problem, i assume that ffdshow creates a 25fps media type at the beginning, and offers that to madVR, but afterwards ffdshow probably updates the media types to 29.97 because it figured out the real frame rate, but then its too late for madVR.

[Neeto]

madVR requests a certain stride of the image, which means the video decoder is asked to actually produce a image 1024 pixels wide, but only with 704 pixels of actual image. This is usually done to ensure that optimized algorithms that only work on a certain amount of pixels at one time can do their job properly.

For the frame rate problem, i assume that ffdshow creates a 25fps media type at the beginning, and offers that to madVR, but afterwards ffdshow probably updates the media types to 29.97 because it figured out the real frame rate, but then its too late for madVR.

I've noticed that when ffdshow has the "DVD decoding" unchecked it also says "16:9" but when cheked it says "4:3" for the 1024x420.
So I suspect it's madVR saying "hey I've got a 16:9 screen to render to could you supply me such a feed" then ffdshow stuffs it up putting 1024x420 (4:3) at 25fps instead of 1024x420 (16:9) at 29.97, either that or madVR is not asking in the correct way (which I doubt).
Anyway leaving DVD decoding unchecked does not seem to stop DVD's from being decoded, so I'm a happy camper for the time being.

[nevcairiel]

The renderer does not communicate the aspect ratio, thats all coming from the source. The only thing the renderer asks for is the stride, the AR is the source AR, the decoder does not care about it.

[peckec]

Hmmmm... Just imagine you didn't have Reclock. Wouldn't in that case 1080p59 be better than 1080p24? That's how madVR thinks. Older madVR versions behaved differently due to a bug. I understand, though, that due to Reclock 1080p24 is preferred over 1080p59. BTW, why don't you have 1080p23 in that list? That would be the best way out.


Thanks for explaining, now i understand. Afaik all movies are shot at 24 frames per second, that's why i'm speeding up 23.976 movies to 24 with ReClock. I know that 1080p23 works as expected and probably i have to use it from now on.

[Budtz]

I have bin thinking about switching from ffdshow to LAV CUVID decoder. Saw som forums where ppl stated that LAV CUVID together with madvr is the best picture quality. No proper arguments as to why thou..

any1 know the difference between theese two decoders?

[fairchild]

I have bin thinking about switching from ffdshow to LAV CUVID decoder. Saw som forums where ppl stated that LAV CUVID together with madvr is the best picture quality. No proper arguments as to why thou..

any1 know the difference between theese two decoders?

The main one I would think would be the higher quality hardware based deinterlacing for interlaced content. Aside from that I'm not sure, might want to read through the LAV CUVID decoder thread.

[SamuriHL]

The PQ comes from madVR. The decoder's job is simply to decode the frames and pass them to the renderer in a timely fashion. The hardware deinterlacing, however, is a definite plus. One of the things that has me thinking about switching my main HTPC to an nVidia card. I'm going to wait til the new generation comes out. Maybe this fall.

[pie1394]

I have bin thinking about switching from ffdshow to LAV CUVID decoder. Saw som forums where ppl stated that LAV CUVID together with madvr is the best picture quality. No proper arguments as to why thou..

any1 know the difference between theese two decoders?

For DTV interlaced contents, LAV CUVID can utilize the pixel-adaptive deinterlacer + other image enhancement (video post-processing) done by the GPU (+ optimized by nVidia). These advanced algorithms require the computation power and memory bandwidth which go beyond the number that x86 CPU can afford. (Just like the advanced scaler options in madVR)

It just requires 1 additional overhead to copy image back to MB DRAM and accessed again by GPU (a requirement by madVR / Haali type renderers).

For regular MS-defined DXVA processing pipeline, the image frame buffer is always inside the GPU before it is handled by all other video post-processings + final presentation by EVR. The early GPU's video processing pipelines are hard-wired by the DXVA spec to save chip cost.

Since ATI R600 and nVidia G80, the GPU architecture has been changed entirely. Thus DXVA is not the only video processing method that GPU HW can support.

[Budtz]

Thx guys.

I just tried it and it seems there are no shapnes, debanding an other postprocessing. Since i get an amazing picture close to when i watch a bluray on my standalone player with the sharpness at around 35, its pretty unsharp without ffdshow.

So ill be sticking with that i think

[Portioli]

i am running mpc-hc--> ffdshow raw video filter (subtitles & SVP)-->cyberlink ham ---> madVR
and i get all the actor faces blue like avatar, i think this happens cause of wrong color conversions.
how i could fix that?

[HTPC-User]

Hi!


Not sure I understand your question. Tell me which modes you want madVR to use and I can tell you what to enter there.


Ok, I try to explain it in more detail: My LCD TV supports for example 1080i50, 1080i60(and 59), 720p50, 720p60 (but no 24Hz modes).
But in ATI's CCC I must set 1080i@25Hz to select 1080i50, 1080i@30Hz for real 60Hz interlaced etc.
So do I have to write 1080i50 or 1080i25 in the display changer line?

My projector supports all usual modes, 1080p23.976, 1080p24, all progressive and interlaced modes up to 1080i/p@60, but here the modes are clearly named: 1080p@24 or 1080p@50. So I guess for the projector I have to specify for example: 1080p23.976?

Concerning my partly grey OSD:

The OSD is drawn half transparent, so the colors of the background are shining through. That may make some pixels appear grey. This can happen if the background is mostly blue and red, because green + blue + red = grey.


I will investigate this issue further in the next few days, but at the moment I am quite sure, that some parts of the OSD are always in green and some parts are in dark grey, no matter what color the background was.
So my first thought was that this might be an ATI bug or a projector problem.

By the way, how can I cross-check if the graphics card as well as the projector displays full RGB 4:4:4?

:thanks:

[crypter]

@madshi

Is it feasible to implement advanced image scaling techniques from super-resolution frameworks (like this one (http://www.cs.huji.ac.il/~raananf/projects/lss_upscale/index.html)) on madVR as real-time resize filters?

[TheElix]

@crypter
Wow, that would be great indeed, though I've gotta admit that Glasner et. al. [2009] and Geniue Fractals (TM) in those comparison images looks better most of the time.

[starkline]

Hoping someone on the d9 forums can help with my odd problem.

Firstly, madvr is working wonderfully for me, but not during playback of some WMV3/WMA2 files. The files load and play fine, so long as I do not seek too many times. When I seek through the file using MPC's seek bar, MPC hangs returning the following:

Problem Event Name: AppHangB1
Application Name: mpc-hc.exe
Application Version: 1.5.2.3237
Application Timestamp: 4df933b4
Hang Signature: 9786
Hang Type: 1
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Hang Signature 1: 978647dc503356c8934aca4eea927783
Additional Hang Signature 2: 62de
Additional Hang Signature 3: 62de8532f75b6ebdc280d2d48c1c947b
Additional Hang Signature 4: df46
Additional Hang Signature 5: df46ddc89a14eac1e45010652d9f6dab
Additional Hang Signature 6: bf6d
Additional Hang Signature 7: bf6d6a4b3ac47a09caa89fbe743d4543


Thing is, when I seek using madvr's seek bar in exclusive mode, the crash doesn't occur.

I've tried all I can think of to troubleshoot this behavior. This includes changing decoder codecs in ffdshow, changing any madvr setting I can access, changing MPC-HC's external filters (and their priority), sweeping nvidia drivers and reinstalling the most current, and I've changed my output from madvr to VMR9 and EVR.

I may be seeing something not related to madvr because switching to VMR9 or EVR still results in the same problem. However, I did not see this problem before switching to madvr 2 or 3 months ago.

The only fix that I've managed to find is to use either MPC-HC's internal WMV Transform Filters, or to force the use of WMVideo Decoder DMO in external filters. I guess that's no big deal, but seeking is slow to the point of unusable with either fix.

I appreciate any suggestions or help, or if people with more knowledge than I clearly see this as not a madvr issue, I'll move along to another place. :)

Software: MPC-HC x86 1.5.2.3237 / ffdshow x86 rev3882 / haali 1.11.96.14 / madvr .65 / Geoforce 275.33

[jmone]

What are the relative merits / drawbacks of Exclusive Mode VS Full Screen Windowed Mode in madVR?

[bur]

When I have an MPC-HC window open when I sent the computer to hibernation after restarting MPC takes up a full core. The whole system gets very slow and unresponsive until I close MPC. This only happens when I use Mad-VR as renderer.

The rendering settings:


enable automatic fullscreen exclusive mode
use separate device for presentation

Windowed mode:
3 backbuffers
flush
flush & wait
don't flush
don't flush


Win 7 x64
Athlon II X4
HD 5770

[bur]

I may be seeing something not related to madvr because switching to VMR9 or EVR still results in the same problem.If that's the case, then it's not MadVR related.

To make 100 % sure you should uninstall MadVR and see if the problem persists. If so, there's maybe something wrong with these files. Did you try playing them elsewhere.

[Hypernova]

@madshi

Is it feasible to implement advanced image scaling techniques from super-resolution frameworks (like this one (http://www.cs.huji.ac.il/~raananf/projects/lss_upscale/index.html)) on madVR as real-time resize filters?

I think madshi said (way before) that he is willing to add advance algorithm. It's just that someone has to give him the code i.e. he do not want to write the implementation himself.

[jmone]

I can't believe I'm thinking of upgraded my HTPC to a i7-2600K (passmark 9,664). My current HTPC [Shuttle (SG45H7), Q6600 (passmark of 2,981), HD5670] plays just about everything but 1080/50 or 60p material push it and it drops frames on interlaced 1080/50 or 60i x264 material being deinterlaced with yadif / double frame rate and rendered with madVR - maxing all 4 coures. Even my i7-920 (passmark 5,563) box can't play this content in madVR windowed mode without dropping frames (just fine in Exclusive mode)....so I'm thinking a i7-2600K upgrade should keep those madVR backbuffer (windowed) or present (exclusve) queues from dropping to 0 and give me some overhead for whatever the next performace bump will be!

[yesgrey]

I can't believe I'm thinking of upgraded my HTPC to a i7-2600K (passmark 9,664).
You can always consider buying a NVidia card instead and start using LAV CUVID. ;)

[jmone]

You can always consider buying a NVidia card instead and start using LAV CUVID. ;)

Mmmm Good Idea and much cheaper! Unfortunatly, I know zip on Nvidia stuff (all ATI for years), SamuriHL suggests a GTS450 for madVR / LAV CUVID duties (I need a quiet low heat or back venting card to put in the Shuttle). Other suggestions?

[SamuriHL]

Mmmm Good Idea and much cheaper! Unfortunatly, I know zip on Nvidia stuff (all ATI for years), SamuriHL suggests a GTS450 for madVR / LAV CUVID duties (I need a quiet low heat or back venting card to put in the Shuttle). Other suggestions?

A 430 isn't powerful enough to handle the content you want to throw at it. The 450 is a great compromise between power noise and heat.

[yesgrey]

Mmmm Good Idea and much cheaper! Unfortunatly, I know zip on Nvidia stuff (all ATI for years), SamuriHL suggests a GTS450 for madVR / LAV CUVID duties (I need a quiet low heat or back venting card to put in the Shuttle). Other suggestions?
I would go for the new version equivalent to the GTS450, the GTX 550 Ti. Slightly pricier, but a little more performance/lower power consumption. You might want to consider also the GTX 560, considering that you would get 50% more of performance for 30% more of price.
See here (http://www.geforce.com/#/Hardware/GPUs/geforce-gtx-550ti/performance) a graph with the performance comparison.

[ney2x]

I would go for the new version equivalent to the GTS450, the GTX 550 Ti. Slightly pricier, but a little more performance/lower power consumption. You might want to consider also the GTX 560, considering that you would get 50% more of performance for 30% more of price.
See here (http://www.geforce.com/#/Hardware/GPUs/geforce-gtx-550ti/performance) a graph with the performance comparison.

+1 I have EVGA GTX 560 Ti and Intel Quad Q9550, no bottlenecks in everything. Pair it with LAV Suite (LAV CUVID and LAV Filters) + madvr + Reclock = perfect (0 drop/glitch)

[Andy o]

I still have my 460GTX gathering dust. Although I see some reasons to use it, like the ones mentioned above, the silent stream bug, um, bugs me. Also, my 5770 gives me near-perfect 23.976, but I guess since I'm decoding with LAV everything now, it doesn't matter as much (ReClock!). Nvidia HDMI audio is still lacking in support, I'm not hopeful they'll fix bugs any time soon.