madVR - high quality video renderer (GPU assisted)

[iSunrise]

Nearest Neighbour for Chroma will give horrible results. Find a movie with a red on black contrast, and you'll see how nearest neighbour looks like crap.
A 4:2:0 chroma subsampling has lost alot of info from the source, so you need some kind of interpolation to restore it, otherwise it may be true to the file, but not true to the source at all.
I understand and agree completely, this looked horrible with the old madVR algorithm.

But from what I´m seeing, I´m under the impression that something seems to have changed.
Have you actually tested it with real content and the new madVR algorithm?

Do you happen to have a sample with red on a black background so I can test it? Thanks in advance.

And while we´re at it, what are your settings for chroma?

[leeperry]

But many cases of visible banding in content is caused by poor levels conversions, the conversion from YUV to RGB, or other processing done by decoders/filters. There are definite real-world improvements from using madVR. Depending on your display, they may be more or less noticeable. (so many flat panels introduce banding themselves)
Mostly because 8bit YCbCr doesn't equal 8bit RGB...this is a very lossy process, and even though there are some Avisynth plugins to avoid the TV>PC levels conversion induced banding using smart dithering(but not debanding, these are two separate things), it's indeed much wiser to do the YCbCr>RGB conversion in mVR than using some dodgy conversion in the decoder...that's really not a decoder's job anyway. But I'm beating a dead horse here :p

[fastplayer]

Do you happen to have a sample with red on a black background so I can test it?
Try this: http://www.mediafire.com/?7oror3hfvbigy8v

PS: Accent != apostrophe (http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html)

[6233638]

JYMI, did you had the chance to rerun your chroma tests with the new madVR logic yet?Bicubic 75 still ended up producing the best results in my tests.

What would be interesting to see, but probably isn't worth you spending any time on, is if we could somehow get separate luma/chroma screengrabs (perhaps as to greyscale image) to do some kind of a visual comparison. E.g. layer the two on top of each other in photoshop with the "difference" filter to see which has the best edge reproduction.

I still maintain that the softer algorithms (high levels of softcubic) spread the chroma out too much, leading to it bleeding out the edges of objects, and desaturating finer details.


@6233638: I would be interested in your input as well.2D videogame footage is probably about the only scenario where nearest-neighbour scaling would work well, for all other content (TV/Film, 3D game footage etc.) it looks really bad.

For downscaling, which isn't something I really do any more, Lanczos4 seemed to produce the best results.

[TheShadowRunner]

Thanks for your extensive reply.


I don't really like the idea of external applications changing display modes behind madVR's back. Of course madVR shouldn't crash in that case, I don't know why that happens. But fixing this problem wouldn't be easy and I don't have much time for madVR at the moment, so I'd prefer to spend the limited time I have on other things.

Sure, I understand. If you make madVR's internal display changer more configurable, it's not even an issue anymore as RunEvent becomes de facto obsolete. ;)

I do plan to rewrite the display mode changer to make it more powerful in a future version.

Please by all means do, if we could set cases not only based on framerate but also source height, that'd be just stellar. ReClock allows that via RunEvent (http://videoff7.free.fr/RunEvent.txt) and it's the only real feature missing ^^;

I'm wondering why you're using a different resolution for SD content, though? Do you have a CRT? With a fixed resolution display you would probably get better image quality if you let madVR scale directly to the display resolution.

I output to a HDTV via HDMI, single output. The reason is simple, the less scaling I do on the player side, the best.

I don't know. There are a lot of things you can adjust with keyboard short cuts. You're now asking for an OSD button. Next thing you (or someone else) might ask for is buttons for all the other things you can currently only activate through keyboard shortcuts. I don't really like the idea of adding buttons for all these things. Well, maybe in some future version, but not anytime soon. The filter's property page is a very unfriendly place to add controls to, that's why I intentionally made it almost empty. I don't have to ever change it, the way it currently works.

No worries, I understand there are more important priorities and indeed the property page isn't the ideal place to put such features anyway.

[nevcairiel]

I output to a HDTV via HDMI, single output. The reason is simple, the less scaling I do on the player side, the best.

For digital displays you should always output their native resolution. I doubt your display does a better job at upscaling then madVR.

[iSunrise]

Try this: http://www.mediafire.com/?7oror3hfvbigy8v

PS: Accent != apostrophe (http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html)
Great sample, thanks a lot.

2D videogame footage is probably about the only scenario where nearest-neighbour scaling would work well, for all other content (TV/Film, 3D game footage etc.) it looks really bad.
Ok, so I wasn't imagining things, but instead my sample doesn't translate very well to TV/Film. I'm still wondering though, why you would choose SoftCubic 70, since it considerably darkens the reds in the upper sample and it also hides source information. While that may be OK on this particular sample, on real TV or Film content, this alters the colors and also kills a lot of fine details, right?

On a Blu-ray which has been mastered carefully (lots of wanted noise is still intact) this noise and the fine details will get smoothed out. I can understand though, that on still images, SoftCubic 70 looks good to the eyes at first.

[TheShadowRunner]

For digital displays you should always output their native resolution. I doubt your display does a better job at upscaling then madVR.

Well I'd rather scaling be done by my HDTV in hardware than on the PC side, just personal preference, not claiming it's the best solution either. ^^

Regardless, ReClock's display changer allows to do that, it'd just be very welcome if madVR could do it too [take sourceheight into account for its display changer] since currently ReClock's display changer crashes madVR 80% of the time. There are other applications besides my own use too, if only for people using high-end dedicated standalone upscalers.

[QBhd]

Thanks madshi for madVR 0.74.

Bug report:

I´ve reproduced a crash issue with PotPlayer and madVR 0.74 at first, but after careful testing, this seems to happen all the way back to and including madVR 0.67, when the internal madVR decoders were introduced.

This crash only happens when you first play a video where PotPlayer´s internal decoders are used and then you open another video, which is then using the madVR decoder (ffmpeg/libav) for h.264. It doesn´t matter if you either open the second video while the first one is still playing or you stopped playback after the first video before loading the second video.

These are the steps to reproduce:

1) Configure PotPlayer to use the internal decoders for everything except H.264 and AVC1
2) Configure PotPlayer to use madVR decoders for H.264 and AVC1
3) Configure madVR to use the ffmpeg/libav decoders for h.264
4) Play any video which is not using H.264 or AVC1 (e.x. WMV3 or XVID or DIVX)
5) While playing or after stopping playback, open another video which is using H.264 or AVC1 (so the madVR decoders need to be invoked)
6) PotPlayer now produces a crash popup which points to madVR.ax

This is 100% reproducible on my system and happens every time.

I´ve uploaded a log with madVR 0.67 and madVR 0.74 and a screenshot of the crash popup window here:
http://www.mediafire.com/?2vxxc79dct86jnf

FYI, I´ve let the first video run for about 9 seconds and opened the 2nd video right at the 10 second mark with both 0.67 and 0.74.

This is exactly the problem I reported a while ago http://forum.doom9.org/showthread.php?p=1520086#post1520086

I gave up using madVR as a decoder for just this reason.

QB

[madshi]

Well I'd rather scaling be done by my HDTV in hardware
Why ?

[TheShadowRunner]

Why ?

I just find the TV's built-in scaler very efficient at what it does on SD/720p sources, enough for my taste, and obviously on the PC side it majorly reduces required processing power and prevents any issues/glitches scaling by the renderer/video card could produce.

What I'm after with madVR is really stability, fullscreen exclusive mode + ReClock is just wonderful.
1 frame skip every 3 days!? Can't beat that ;)

So yeah, if you can implement a more complete display changer to achieve what ReClock's Runevent does, awesome. Otherwise I'll just try to find a way to make RunEvent coexist with madVR, but i'm not very optimistic.

[STaRGaZeR]

I've only very limited time at the moment and adding a bunch of new controls can be quite time consuming. Especially things like allowing to choose installed decoders etc. That's not just a checkbox, that probably requires a full new dialog, a listing of installed decoders and all that kind of stuff. There are so many things I want to implement and I have to sort things, most important things first. I believe that e.g. deinterlacing is more important than these manual RGB input level overwrite controls. So I'm going to look into deinterlacing first. Can't do everything at the same time.

That's why I say that it sounds complex. An RGB passthru checkbox next to the level settings, on the other hand, is easy and fast to do and would work fine for the time being IMHO. *Please*, so I can keep using madVR :D

That's true. That's why I would really like to add autodetection for at least all common filters. E.g. I can read out the registry to check which filter is configured which way etc. Not a big problem. I've already checked: CoreAVC stores its settings in an ini file, which I could read out to check which output levels are used. Of course that doesn't make sense right now cause CoreAVC always outputs PC levels for RGB. But you get the idea. I could do the same for all other important filters. This would mean that all "known" filters would automatically work alright, regardless of how the user configures them. The manual controls would only be needed for filters unknown to madVR.

Yeah, that's what you do now with ffdshow, right? Look in the registry.

But many cases of visible banding in content is caused by poor levels conversions, the conversion from YUV to RGB, or other processing done by decoders/filters. There are definite real-world improvements from using madVR. Depending on your display, they may be more or less noticeable. (so many flat panels introduce banding themselves)

That's why I say that I haven't found any of that banding here yet. I usually find a crapload of banding already on the source instead. And that banding has nothing to do with low quality conversions on the player's end.

[JarrettH]

What does 'Presentation Glitches' mean regarding the OSD information? :thanks:

[Xaurus]

madshi,

I am getting extremely confused by all the black level stuff.

I recently switched to RGB in Nvidia control panel after reading
that selecting YCbCr444 isn't really beneficial since it will just
be converted from RGB internally in the graphics card, not output "pure".

I am also confused by setting RGB in the control panel since I
must set my plasma to "low" black level setting (video levels)
in order to not get a washed out screen. It is sent from DVI
to HDMI, so it seems it is outputting RGB video levels.
I thought the RGB default was 0-255.

Because on my computer monitor I have also set to RGB and
here it seems it is sending out 0-255...

*confused*

Anyway, in order to configure madvr I encountered an issue
that just made things worse.

I've used the HD 709 (http://www.wuala.com/alluringreality/Public/MP4-2c.7z) Black Level test:

madvr:
screenshot (http://home.halden.net/mordor/madvr_16_235.png)

And here with EVR custom set to 16-235:
screenshot (http://home.halden.net/mordor/evr_custom_16_235.png)

Now I ask, why is this different? Shouldn't they produce the same results?

edit: All gamma and other brightness/contrast settings are disabled

[SamuriHL]

nVidia generally require you to create a custom resolution to get PC levels on RGB. Try creating a custom resolution and see if that fixes your black level issue.

[nevcairiel]

Create a custom resolution, then you'll get RGB 0-255 output. There is also another way to enable full range RGB output, but its a bit more demanding. :p

NVIDIA cards behave a bit weird with madVR, they always assume your image is full range, and compress it to limited range if required. So with NVIDIA, you should basically always have madVR set to full range to avoid double compression.
With EVR its different, probably because the driver is in Video mode, and not in Game mode.

Thats my experience, anyway.

[Xaurus]

SamuriHL & nevcariel,

Thank you so much, I totally forgot about this custom resolution stuff. It fixed my issue.

As for "content type reported to the display", does the choices here matter? I have tried
the two options but can't see a difference.

Also in the Video -> Adjust video color settings -> How do you make video color adjustments?
Does this have to be enabled (Nvidia settings) or can I disable this (application settings)?

Even if I have it enabled and do adjustments, nothing makes an impact on the video I am playing...
However, making adjustments in "Adjust desktop color settings" makes a huge impact, kind of contradictory
since it seems to me like it shouldn't affect video settings, only desktop settings...

Thanks again, much appreciated. Gotta say though, Nvidia makes this really difficult for us normal people. :)

[SamuriHL]

I have to set that option to video on my machine else it causes MAJOR problems with interlaced content going through my Pioneer 820-k. Honestly I have no idea what it really does. I recommend auto if it works for you.

[leeperry]

Gotta say though, Nvidia makes this really difficult for us normal people.
Well, at least they allow us to set custom res...if you ask the AMD techsupport, they'll tell you to try your luck w/ pstrip or rivatuner...which aren't officially supported and are mostly dirty hacks at heart, w/ very random results sometimes. Of course, they also require buggy system drivers to be installed and a few TSR's as well.

And no CUDA either, because AMD didn't see GPGPU as an important feature to support...they're only interested in hacking a few fps in the latest games in order to look good in games charts.

[Xaurus]

It seems I was too fast for a celebration - I got the custom resolution set up nicely with frequency and stuff, but the graphics card is still outputting RGB 16-235. Sigh.

So I guess I just go to sleep now, fed up by this. :)

Sorry madshi for taking your thread off-topic.

[nand chan]

Hey madshi,

Can you give me a list of all strings that madVR searches for in the parameters file of a .3dlut, and what kinds of information it extracts?

Would it be possible to add new alternatives as well? For example, instead of “Input_Range 16 235” I would like to use something similar to “!Input_Range(16,235)”, or “!Input_Range(Limited)”. Would you be able to implement either of these within a foreseeable time-frame?

Also, does madVR scan for the Output Range as well or just the input range?

And no CUDA either, because AMD didn't see GPGPU as an important feature to support...they're only interested in hacking a few fps in the latest games in order to look good in games charts.

That's because CUDA is proprietary and controlled by nVidia. AMD supports OpenCL just fine, and if you use CUDA instead of OpenCL for GPGPU computing you have nobody to blame but yourself.

AMD has also always had Stream. Regardless of whether or not games support it, saying AMD “doesn't see GPGPU as an important feature to support” is a claim beyond the realms of ridiculousness.

In fact, AMD FirePro/FireStream are quite a bit better for professional work than the nVidia Quadro line, and AMD had 10-bit support before nVidia even began caring about it. Chances are, AMD will be the first company to introduce 10-bit support in Radeon drivers, some estimates say we might be getting it by the release of the HD 7xxx cards.

But that's going off-topic.

[leeperry]

That's because CUDA is proprietary and controlled by nVidia. AMD supports OpenCL just fine, and if you use CUDA instead of OpenCL for GPGPU computing you have nobody to blame but yourself.
Indeed, but to have an OpenCL h264/VC1 decoder working, AMD seem to expect coders to recreate the wheel. OTOH, nvidia have perfectly working hardware decoders that can be used via CUDA, mostly acting as a wrapper. Nobody seems to be interested in writing such decoders from scratch...not even CoreCodec. That's how I understood it anyway....and surely, they will have to get that job done if they wanna sell their forthcoming APU's (http://blogs.amd.com/play/2011/06/20/opencl-combined-with-amd-fusion-apu-leads-the-way-for-gpgpu-computing-acceleration/) to anyone. They've missed the HTPC train completely as far as I can see, so blaming nvidia for their drivers doesn't make much sense to me...especially when creating custom res on AMD requires the uber-bloated pstrip :D

[nand chan]

Indeed, but to have an OpenCL h264/VC1 decoder working, AMD seem to expect coders to recreate the wheel. OTOH, nvidia have perfectly working hardware decoders that can be used via CUDA, which mostly acts as a wrapper. Nobody seems to be interested in writing such decoders from scratch...not even CoreCodec. That's how I understood it anyway....

You mean like Avivo and DXVA? I believe it's also accessible from OpenCL just fine.

and surely, they will have to get that job done if they wanna sell their forthcoming APU's (http://blogs.amd.com/play/2011/06/20/opencl-combined-with-amd-fusion-apu-leads-the-way-for-gpgpu-computing-acceleration/) to anyone. They've missed the HTPC train completely as far as I can see, so blaming nvidia for their drivers doesn't make much sense to me...especially when creating custom res on AMD requires the uber-bloated pstrip :D

You can create custom HDTV formats (like 1080p24) in the CCC, and you can do whatever you want by editing the .xml profiles (even changing the 2D clocks and overvolting etc, basically things that you can't change in the CCC). I'm not saying it's pretty, but it's possible - for those who require it.

[Andy o]

That's weird, was this bug introduced relatively recently? I don't remember having these issues with the GTX460.

[dansrfe]

I'm not sure if this is an appropriate complaint/concern but madVR drops frames whenever my desktop background changes wallpapers. I'm on W7, ATi Radeon, MPC-HC latest, ffdshow latest, madVR v0.74.

[mzso]

I just find the TV's built-in scaler very efficient at what it does on SD/720p sources, enough for my taste, and obviously on the PC side it majorly reduces required processing power and prevents any issues/glitches scaling by the renderer/video card could produce.
It still doesn't make sense to me. As far as I understand madVR bypasses any crappiness your card can do, so unless you have a broken driver you probably end up with better quality. As for processing power. Are you really that cheap that the few extra watts that your card uses bothers you?

[TheShadowRunner]

It still doesn't make sense to me. As far as I understand madVR bypasses any crappiness your card can do, so unless you have a broken driver you probably end up with better quality. As for processing power. Are you really that cheap that the few extra watts that your card uses bothers you?

It doesn't have to. Enjoy your obviously superior setup that's not cheap. Have a good day.

[6233638]

I just find the TV's built-in scaler very efficient at what it does on SD/720p sources, enough for my taste, and obviously on the PC side it majorly reduces required processing power and prevents any issues/glitches scaling by the renderer/video card could produce.As someone who has spent a lot of time with various HDTVs from all the "big name" manufacturers (LG, Panasonic, Philips, Pioneer, Samsung, Sharp, Sony, Toshiba etc.) I can easily say that the built-in scaling quality pales in comparison to what madVR is capable of. And madVR is flexible enough that it lets you get the kind of image you want by selecting the algorithm that suits your tastes.

It certainly reduces the load on your GPU to avoid madVR doing any luma scaling, but I don't understand what you mean by "prevents any issues/glitches scaling by the renderer/video card could produce"


That's why I say that I haven't found any of that banding here yet. I usually find a crapload of banding already on the source instead. And that banding has nothing to do with low quality conversions on the player's end.Even with highly compressed content, I have noticed a definite reduction in macroblocking as a result of using madVR thanks to the increased precision. I would be very surprised if there was much content out there that doesn't benefit from madVR's precision to some degree.

I am getting extremely confused by all the black level stuff.The first thing I would try, is to select 1920x1080 from the "PC" section of the resolution list if it's there.
If not, try creating a custom resolution.
Other than that, try going to "adjust desktop color settings" and make sure you are not using "nvidia settings", digital color format is set to RGB and content type reported as "games." (I imagine that "desktop programs" would also work)
Restart your PC after making these changes.

Hopefully this will get your PC to output the full range 0-255 to your display.


With regard to the screenshots you have posted, the labelling in madVR is essentially the opposite of what most video renderers use.

With madVR if you set your display to 0-255, it will clip all values below 16 and above 235 because you're telling it that your display won't.

If you set your display to 16-235, it outputs the full range with the expectation that your display is going to clip below 16 and 235.

In my opinion, this is the correct way to handle the setting, and the other renderers are going about it backwards.


(Well, almost correct. Values above 235 would ideally not be clipped by the renderer or the display, but values below 16 should)

in the Video -> Adjust video color settings -> How do you make video color adjustments?
Does this have to be enabled (Nvidia settings) or can I disable this (application settings)?These settings have no effect on madVR but will affect many other renderers.

It seems I was too fast for a celebration - I got the custom resolution set up nicely with frequency and stuff, but the graphics card is still outputting RGB 16-235. Sigh.It's possible that your display's EDID is reporting that it can only accept 16-235. (in which case there's nothing you can do about it) Many HDTVs completely screw this up.

There are even HDTVs out there that fully support 24p but do not report that fact, and so you can only send them 24p if you have the option to force it. (this is why they added that option to the PS3 for example) Many sources/players simply won't allow 24Hz output unless the display says it will accept it.

[mzso]

With regard to the screenshots you have posted, the labelling in madVR is essentially the opposite of what most video renderers use.

With madVR if you set your display to 0-255, it will clip all values below 16 and above 235 because you're telling it that your display won't.

If you set your display to 16-235, it outputs the full range with the expectation that your display is going to clip below 16 and 235.

In my opinion, this is the correct way to handle the setting, and the other renderers are going about it backwards.


(Well, almost correct. Values above 235 would ideally not be clipped by the renderer or the display, but values below 16 should)

These settings have no effect on madVR but will affect many other renderers.

It's possible that your display's EDID is reporting that it can only accept 16-235. (in which case there's nothing you can do about it) Many HDTVs completely screw this up.

There are even HDTVs out there that fully support 24p but do not report that fact, and so you can only send them 24p if you have the option to force it. (this is why they added that option to the PS3 for example) Many sources/players simply won't allow 24Hz output unless the display says it will accept it.
Why does even this 16-235 limit exist? Do many TV's support 0-255?

[6233638]

Why does even this 16-235 limit exist? Do many TV's support 0-255?Televisions have traditionally always worked in Video Levels (16-235) whereas it was only PCs that used full range (also called PC Levels) 0-255 signals.

It is only in recent years that many HDTVs have started to accept full range 0-255 signals, and support for them is still almost universally poor.

My Sony HX900 allows me to set each HDMI port to "Full/Limited" range, but my PC only ever seems to send it 0-255, even when my resolution is selected from the "HD, SD" list. (at least when that port is set to Full Range - I've never tried anything else)

I had a Sony projector of a similar age that supposedly supported a full range signal, and would work correctly when sent it from a PS3, but when sending 0-255 from a PC the projector was stuck in the 16-235 video mode, with no option to override it.

Prior to that, most HDTVs I had required using a VGA cable rather than HDMI to support PC levels correctly. Hell, many of them even just a few years back would overscan everything (even a 1080p input) unless you used VGA.


I cannot understand why Nvidia makes things so complicated though. Rather than listing resolutions twice under an "HD, SD" or "PC" heading, or requiring you to create custom resolutions, they just need a dropdown below the refresh rate/color depth ones that says:Levels: Auto PC (0-255) Video (16-235)

[STaRGaZeR]

Even with highly compressed content, I have noticed a definite reduction in macroblocking as a result of using madVR thanks to the increased precision.

¿?¿?

Do you even understand what madVR's "increased precision" is or affects to?

[CruNcher]

Indeed, but to have an OpenCL h264/VC1 decoder working, AMD seem to expect coders to recreate the wheel. OTOH, nvidia have perfectly working hardware decoders that can be used via CUDA, mostly acting as a wrapper. Nobody seems to be interested in writing such decoders from scratch...not even CoreCodec. That's how I understood it anyway....and surely, they will have to get that job done if they wanna sell their forthcoming APU's (http://blogs.amd.com/play/2011/06/20/opencl-combined-with-amd-fusion-apu-leads-the-way-for-gpgpu-computing-acceleration/) to anyone. They've missed the HTPC train completely as far as I can see, so blaming nvidia for their drivers doesn't make much sense to me...especially when creating custom res on AMD requires the uber-bloated pstrip :D

Ehh for that AMD released the OpenDecode API for their UVD DSPs like Nvidia did before with Nvcuvid for their VPx DSPs you don't have to write any OpenCL Decoder but can leverage both though Nvidia was much faster with this 1 year to be exact on a broad non NDA scale release also Nvidias Ecosystem for Developers and support was excelent it was a WIN WIN WIN situation (Developer,Nvidia,Customer) though AMD lost ground here also because of several Security issues about HDCP and their DSPs that also made Linux support problematic.
AMD only released it @ first under strict NDA (most probably because they feared HDCP could be compromised, and it would require a lot of efforts to create a Inteface that avoids that) thus Nvidia got more and more support (every small Developer could utilize it without signing a NDA and get a complete supported Source and support even contacting Nvidia directly in the beginning of this was no problem, they loved all the feedback to improve see Donald Grafts story being one of the first non big company Developers who utilized it straight from the beginning and how Doom9 feedback improved it over time later CoreCodec and other Companies joined in) for the VPx with their more open Developer approach AMD later pushed more resources into the OpenDecode approach also because of the upcoming APUs but it was really late a solution was already announced back then with the Stream SDK but it took till the APP SDK (APU Move) until OpenDecode was actually being released to a wider public.
Later Intel was not as dumb as AMD back then and gone the same way with their Intel Media SDK for the Intel HD Graphics Decoder as Nvidia did.

[nevcairiel]

Ehh for that AMD released the OpenDecode API for their UVD DSPs like Nvidia did before with Nvcuvid for their VPx DSPs you don't have to write any OpenCL Decoder but can leverage both though Nvidia was much faster with this 1 year to be exact on a broad non NDA scale release also Nvidias Ecosystem for Developers and support was excelent it was a WIN WIN WIN situation (Developer,Nvidia,Customer) though AMD lost ground here also because of several Security issues about HDCP and their DSPs that also made Linux support problematic.
AMD only released it @ first under strict NDA (most probably because they feared HDCP could be compromised) until they realized Nvidia gets more and more support for the VPx with their more open Developer approach.

Except that AMDs API is somewhat limited, alot harder to use, and generally lacking - which may have something to do with OpenCL in general being really alot harder to use then CUDA.
The CUVID API piped through CUDA is so trivial to use, and so easy to implement.. its no surprise its supported in various products while ATIs API is not.

[6233638]

¿?¿?

Do you even understand what madVR's "increased precision" is or affects to?I do. The visibility of macroblocking is directly related to the precision of the display chain. It's why macroblocking was so much less visible on CRTs compared to flat panels, and why older HDTVs made it so much more visible compared to newer sets.

[Xaurus]

6233638,

After spending many hours on this today I have finally solved my issue. I applied this "hack" when installing the Nvidia drivers:

For those of you that didn't know, for whoever has a HDTV connected with nvidia drivers,
and the entire desktop is being output in 16-235 instead of full range, the best workaround is to
add this to the nv_disp.inf before installing the drivers. Makes the drivers assume your using a fullrange TV
instead of limited range. I need to use this each time I do a clean install of nvidias drivers.

Add

HKR,,SetDefaultFullRGBRangeOnHDMI,%REG_DWORD%,1

to each section of your inf that begins with

[nv_miscBase_addreg_

eg

[nv_miscBase_addreg__01]
HKR,,SetDefaultFullRGBRangeOnHDMI,%REG_DWORD%,1

This worked and now I can run full RGB to my Plasma display,
and correctly have to choose "high" black level (0-255) in its menu
to avoid getting a washed out screen.

I also successfully created a custom resolution in the Nvidia
control panel as per these instructions:

http://forums.nvidia.com/index.php?showtopic=153212&view=findpost&p=1197179

So now my screen is fixed at 23.97595 Hz (as good as it gets, I guess)

However, when I use Reclock it won't sync any 23.976 movies.
So I think I will drop this program, as I don't really understand it that well.
Can it only be used when the media frame rate is different from the screen refresh rate?

[STaRGaZeR]

I do. The visibility of macroblocking is directly related to the precision of the display chain. It's why macroblocking was so much less visible on CRTs compared to flat panels, and why older HDTVs made it so much more visible compared to newer sets.

No comment to that :p

[Andy o]

However, when I use Reclock it won't sync any 23.976 movies.
So I think I will drop this program, as I don't really understand it that well.
Can it only be used when the media frame rate is different from the screen refresh rate?Post screenshots of your ReClock settings, for all dialogs, including the settings and the one in the tray when the video's playing.

[Xaurus]

Post screenshots of your ReClock settings, for all dialogs, including the settings and the one in the tray when the video's playing.
Thanks Andy, but I've already uninstalled Reclock as I could
never get rid of a small stutter appearing each 10-30 seconds.

I just watched an episode of Rome (1080p) without Reclock and I had no stutter at all so I guess I'll just skip Reclock altogether.

The only thing I have some problems with are to set the correct
audio delay in ffdshow audio, to sync the sound with the video.
Right now it's set to 40ms but it doesn't seem 100% correct.

[6233638]

Thanks Andy, but I've already uninstalled Reclock as I could
never get rid of a small stutter appearing each 10-30 seconds.That doesn't seem right, not using ReClock is usually the cause of that. (either that or audio sync problems)

I would suggest trying ReClock again. Make sure it is selected as the audio renderer in your player, and not added as an external filter.

http://img231.imageshack.us/slideshow/webplayer.php?id=79075040.png

Note: My sound pre-buffer & max latency settings probably won't work well on most HTPCs, it's only giving the CPU 4ms to process the audio before you start getting pops & clicks. Works fine on a system my spec, probably terrible on others. I'd try 200-300ms and 5%. (basically as low as you can get without audio problems)

Sample rate & format should be set as high as your device allows.

[ajp_anton]

Random question about scaling that I just thought about...
If I'm using a screen that is an integer multiple of the movie resolution, will the original pixels be there with interpolated pixels in the gaps (plus the last row), or will everything sort of get "shifted" into the middle?

[nand chan]

Random question about scaling that I just thought about...
If I'm using a screen that is an integer multiple of the movie resolution, will the original pixels be there with interpolated pixels in the gaps (plus the last row), or will everything sort of get "shifted" into the middle?

I'm guessing shifted. There's a reason it's called upscaling and not interpolation. You want to preserve the original scale.

For example, if you have 2 pixels of black surrounded by 1 pixel of white each in the original, then you want that same 1:2:1 ratio in the upscaled copy.

[cyberbeing]

This was discussed in a thread somewhere here on Doom9 in the past.

Edit: Found it.
unless you are pointresizing up and boxresizing, or pointresizing down, you are losing data.

Interpolation with anything other then an integer power upscale with pixel duplication IE pointresize is lossy. Downscaling is always lossy, unless you are downsizing a previously pixel duplicated/pointresized image, by a factor of the original upscale integer, using either box or pointresize/pixel decimation.

For all practical purposes interpolation is always lossy, but the loss is of managable size and very rarely easily noticible after only one or two interpolation operations with good linear interpolation.

That's right. Naively, one might think that upscaling by a factor of 2 would at least preserve the original pixels, but that's only true for PointResize. All the other resizers preserve the image center position, so all output pixels end up being interpolated.

(If we number the original pixels 0, 1, 2, ..., then the output pixels correspond to positions -0.25, 0.25, 0.75, 1.25, ...)

Interestingly (or maybe not :)), it turns out that upscaling by an odd integer factor actually does preserve the original pixels amongst the interpolated ones. For example, for x3, we get pixels corresponding to -1/3, 0, 1/3, 2/3, 1, ...

iirc, even for 3x, 5x, etc. upscales, the center pixel is stil processed by some of the taps of the filter, IE, for 3x, the center pixel does not get processed by the main blurring lobe, but it gets hit by the following sharpening, and bluring lobes (assuming 3 tap interpolation), I'm not sure how the internals of the functions work, so the center pixels may be bypassed, but otherwise, it is as good as impossible to preserve any of the original pixels. Furthermore, even for 3x, etc. upscaling, you would have to use pointresize downscaling, selecting only the unprocessed pixel positions to get back to where you started, and If you do that instead of at least using box downsizing, their isn't any point in upscaling at all.

You're right that even for 3x, 5x, etc, it does depend on the filter kernel of the specific resizer used.
But actually, most of the resizers (when upsizing) do act as pure interpolators (their kernels have zero crossings at integer distances from the center), so source pixels are preserved where the resampling points coincide.

The exceptions are BilinearResize with b/=0, and GaussResize (except for large values of p, >80 or so).

You can demonstrate this with a script like this:
function UpDown(clip c, int scale) {
w = c.width
h = c.height
up = c.LanczosResize(w, h*scale) # or most other resizers
up.PointResize(w, h, 0, (scale-1)/2.0)
IsYV12(c) ? MergeChroma(up.PointResize(w, h, 0, scale-1.0)) : last
}

... # set source
orig = last
UpDown(5) # or any odd number
Compare(orig)
which will show successful recovery of the source pixels (by point downsizing) after upscaling by an odd multiple.
(If source is YV12, an extra step is required because of differing chroma placement.)

Of course, all this is of mainly academic interest, since I agree that the exercise is fairly pointless. ;)

You are right, that had slipped my mind. So I suppose any resampler derived from sinc in some way (pretty much every linear interpolator except what you listed) would behave this way.

[Xaurus]

That doesn't seem right, not using ReClock is usually the cause of that. (either that or audio sync problems)

I would suggest trying ReClock again. Make sure it is selected as the audio renderer in your player, and not added as an external filter.

http://img231.imageshack.us/slideshow/webplayer.php?id=79075040.png

Note: My sound pre-buffer & max latency settings probably won't work well on most HTPCs, it's only giving the CPU 4ms to process the audio before you start getting pops & clicks. Works fine on a system my spec, probably terrible on others. I'd try 200-300ms and 5%. (basically as low as you can get without audio problems)

Sample rate & format should be set as high as your device allows.
Thanks 6233638, I will give it another shot (not today though).

However, could you post a screenshot of the Reclock properties while a running 23.976 media file with your screen set at 23.976 (or as close to as possible?).
I would be interested to see if it changes the media speed to 24.0000 as it did for me.

In any case, yes the judder was the big issue for me. Couldn't get rid of it, but I'll give it another shot as I said. :)

:thanks:

[nevcairiel]

I would be interested to see if it changes the media speed to 24.0000 as it did for me

It always says that it changes it to 24.000 for 23.976 material, but thats a lie. It always changes it to match your screen as closely as possible.

[robpdotcom]

I know there's a lot of discussion about this, but I can never seem to get it straight:

I have a new projector, which has an option to set the HDMI video range to "expanded". Should I set it to expanded, and set madvr to output PC levels? Or should I set the projector to normal, and set madvr to TV level?

I have my GPU set to RGB full.

[QBhd]

I know there's a lot of discussion about this, but I can never seem to get it straight:

I have a new projector, which has an option to set the HDMI video range to "expanded". Should I set it to expanded, and set madvr to output PC levels? Or should I set the projector to normal, and set madvr to TV level?

I have my GPU set to RGB full.

I am curious as well since I think I have it correct, but would love to here from the experts... I have the GPU set to Full, madVR set to PC Levels and my Plasma set to "High" Black Level (as far as I know this is PC Levels on an LG HDTV)

QB

[betaking]

Hi madshi! big thanks for you work! but i have a small request for madvr!

Can you add a default decoding it on a few if not detected and decoded the library file does not exist is not open in madvr in the corresponding format decoding it? Thank you! because.

[ianken]

I am curious as well since I think I have it correct, but would love to here from the experts... I have the GPU set to Full, madVR set to PC Levels and my Plasma set to "High" Black Level (as far as I know this is PC Levels on an LG HDTV)

QB

Well, since display manufacturers don't typically settle on these terms deciding what's "right" or not can be problematic.

If you are going to a consumer "TV" display and not a "monitor" and you want the least amount of color space conversions you set TV levels in Mad-VR and "limited" in the nvidia control panel. This ensures 16-235 levels go through without molestation and that headroom and toe room are preserved.

You can use this pattern to check levels. Using it as a BMP allows you to bypass any video pipeline stuff and ensure that the display hardware is all calibrated independent of the video pipeline.

BMP:
http://www.ian-kennedy.com/Video/Levels.bmp
WMV:
http://www.ian-kennedy.com/Video/Levels.wmv

When all is done they should match.

Disclaimer: once done things like photos and video games that depend on black == 0 will look too dark as your display should be calibrated to black == 16.

This is NOT for users who want photos, games and video to have matching levels.

If you are going over HDMI, you need to install the NVIDA drivers with a modified INF to get them to not do their HDMI "make everything look right" shenanigans. See below.


Run the driver installation file to the point where the file contents are extracted. Then cancel the rest of the installation.

Go to the folder where the files contents were extracted to.

Search for the file nv_disp.inf and open it.

Search for the section [nv_miscBase_addreg__01]

Under this section add the registry value:
HKR,,SetDefaultFullRGBRangeOnHDMI,%REG_DWORD%,1

Repeat this step for [nv_miscBase_addreg__02] and [nv_miscBase_addreg__03] and so on until all [nv_miscBase_addreg__xx" have the above registry value.

Save this .inf with the changes.

[madshi]

Bicubic 75 still ended up producing the best results in my tests.

I still maintain that the softer algorithms (high levels of softcubic) spread the chroma out too much, leading to it bleeding out the edges of objects, and desaturating finer details.
You're only checking for chroma resolution/detail, though, not for aliasing, are you? Of course it's a matter of taste if chroma resolution is more or less important than avoiding/removal of aliasing. Personally, I hate aliasing, so I prefer to use a softer chroma upscaling algorithm.

It's also worth mentioning that there are different chroma *down*sampling algorithms used by studios for their 4:4:4 -> 4:2:0 conversion. Some use a FIR filter, some use nearest neighbor sampling, some linear filtering, some a tent or box filter. If chroma was downsampled by using a FIR filter, aliasing isn't too problematic. But if chroma was downsampled with nearest neighbor / box then aliasing is *really* bad. I would guess that the sample(s) you've been testing with were probably downscaled using a FIR filter.

What would be interesting to see, but probably isn't worth you spending any time on, is if we could somehow get separate luma/chroma screengrabs (perhaps as to greyscale image) to do some kind of a visual comparison. E.g. layer the two on top of each other in photoshop with the "difference" filter to see which has the best edge reproduction.
Oh well, maybe I should implement *normal* screenshots first, before even thinking about such "special" features... ;)

Well I'd rather scaling be done by my HDTV in hardware than on the PC side, just personal preference, not claiming it's the best solution either. ^^

Regardless, ReClock's display changer allows to do that, it'd just be very welcome if madVR could do it too [take sourceheight into account for its display changer] since currently ReClock's display changer crashes madVR 80% of the time. There are other applications besides my own use too, if only for people using high-end dedicated standalone upscalers.
As I said, I do plan to rewrite/extend the display mode changer. What you're asking for is needed by some CRT users, so I will probably implement it. That said, in your case I think you'll likely get better image quality if you always let madVR scale to the physical resolution of your display.

That's why I say that it sounds complex. An RGB passthru checkbox next to the level settings, on the other hand, is easy and fast to do and would work fine for the time being IMHO. *Please*, so I can keep using madVR :D
I'd prefer to do it the other way round: Tell me which filters you're using and I will make autodetection work properly for all of them. Also I've just decided I will switch autodetection to detect full range input by default if the input is RGB and if madVR isn't sure which levels were used. So basically autodetection will only assume limited range RGB input if I'm sure about that. I think that should reduce the amount of wrong guesses.

Yeah, that's what you do now with ffdshow, right? Look in the registry.
For ffdshow I'm actually querying a special interface exposed by the ffdshow filter instance. Seems to work quite nicely. Not sure yet why your sample makes autodetection fail, must be a simple stupid bug somewhere, haven't had time to look into that yet.

What does 'Presentation Glitches' mean regarding the OSD information? :thanks:
It means that the GPU driver unexpectedly dropped frames behind madVR's back.

Can you give me a list of all strings that madVR searches for in the parameters file of a .3dlut, and what kinds of information it extracts?
madVR requires "Input_Primaries". Also the words "RGB_PC" and "YCbCr" are *not* allowed to be used.

Would it be possible to add new alternatives as well? For example, instead of “Input_Range 16 235” I would like to use something similar to “!Input_Range(16,235)”, or “!Input_Range(Limited)”. Would you be able to implement either of these within a foreseeable time-frame?
madVR doesn't actually look for the Input_Range command at all. madVR simply assumes that the 3dlut is limited range.

Also, does madVR scan for the Output Range as well or just the input range?
madVR doesn't scan for either input range or output range. madVR simply checks that the parameter text doesn't contain the words "RGB_PC" and "YCbCr". This makes sure that older 3dlut files created by older madVR/yCMS versions are not accepted by madVR.

I'm not sure if this is an appropriate complaint/concern but madVR drops frames whenever my desktop background changes wallpapers. I'm on W7, ATi Radeon, MPC-HC latest, ffdshow latest, madVR v0.74.
How often do you change background wallpapers during video playback? :eek:

Values above 235 would ideally not be clipped by the renderer or the display, but values below 16 should
Actually that's open for discussion. There's a thread on AVSForum which extensively analyzed this and the end result wasn't 100% clear. But those who were convinced that WTW shouldn't be clipped at the start of the thread weren't so convinced, anymore, at the end of the thread.

It's possible that your display's EDID is reporting that it can only accept 16-235.
IIRC the EDID doesn't say anything about 16-235 vs 0-255.

Ehh for that AMD released the OpenDecode API for their UVD DSPs like Nvidia did before with Nvcuvid for their VPx DSPs you don't have to write any OpenCL Decoder but can leverage both
Except that AMDs API is somewhat limited, alot harder to use, and generally lacking - which may have something to do with OpenCL in general being really alot harder to use then CUDA.
The AMD API has 2 big problems:

(1) It doesn't support any kind of deinterlacing.
(2) It requires the use of OpenCL, and AMD doesn't support OpenCL <-> D3D9 interop.

Add to that the fact that DXVA deinterlacing is based on D3D9. The end result is that using the AMD API makes no sense at all for interlaced content. I don't really know what AMD is thinking. The missing OpenCL <-> D3D9 interop is a major problem, but AMD doesn't seem to care. They don't seem to know what they're doing, IMHO.

Random question about scaling that I just thought about...
If I'm using a screen that is an integer multiple of the movie resolution, will the original pixels be there with interpolated pixels in the gaps (plus the last row), or will everything sort of get "shifted" into the middle?
Depends on the algorithm. When using linear resamplers (as offered by madVR) the original pixels will not be there. Linear resamplers resample every single pixel. There are algorithms which do integer multiple upscales and leave the original pixels untouched and just interpolate the "missing" pixels. Examples for such algorithms are Nearest Neighbor, NEDI, NNEDI3, ICBI etc...

I know there's a lot of discussion about this, but I can never seem to get it straight:

I have a new projector, which has an option to set the HDMI video range to "expanded". Should I set it to expanded, and set madvr to output PC levels? Or should I set the projector to normal, and set madvr to TV level?

I have my GPU set to RGB full.
First of all you should leave your GPU set to RGB full in either case. Furthermore, of course madVR's level setting must match the display's level setting. If these two requirements are met, image quality should be just fine. Now should you use video levels or PC levels? That's a good question. There's an argument for both. If you use video levels, the processing is somewhat less extensive, so there's an ever so slight chance that the output might be smoother. Thanks to dithering this should not really make any visible difference in the real world though. There's also a good argument for using PC levels: Using PC levels allows you to have correct blacks and whites for video playback, gaming and photos/applications at the same time. So pick your poison. Personally, I'm currently using PC levels.

Can you add a default decoding it on a few if not detected and decoded the library file does not exist is not open in madvr in the corresponding format decoding it?
I'm not sure what you mean exactly. Can you explain this in more words? You're probably using an online translator? The translator didn't do a very good job this time, unfortunately.

If you are going to a consumer "TV" display and not a "monitor" and you want the least amount of color space conversions you set TV levels in Mad-VR and "limited" in the nvidia control panel. This ensures 16-235 levels go through without molestation and that headroom and toe room are preserved.
The "limited" setting in the NVidia control panel should have no effect on madVR, I believe.

[TheElix]

The AMD API has 2 big problems:

(1) It doesn't support any kind of deinterlacing.
(2) It requires the use of OpenCL, and AMD doesn't support OpenCL <-> D3D9 interop.

Add to that the fact that DXVA deinterlacing is based on D3D9. The end result is that using the AMD API makes no sense at all for interlaced content. I don't really know what AMD is thinking. The missing OpenCL <-> D3D9 interop is a major problem, but AMD doesn't seem to care. They don't seem to know what they're doing, IMHO.
Somebody should bring it to their attention, dammit!