madVR - high quality video renderer (GPU assisted)

[nand chan]

madshi thinks that what the decoder should do is if the input is limited range, output it as limited range. If the source is full range, output is as full range. And then let the renderer do its job and convert that if necessary.

I agree with this fully. The decoder should leave the image stream as untouched as possible. The renderer should be in charge of making it display correctly, and it should be the last step in the chain.

If all other renderers don't work like this then all other renderers are doing it wrong and I don't see a reason to conform to them.

[STaRGaZeR]

That is a HUGELY gross overestimate :eek:... more and more "HTPC's" every day are hooked up to Largescreen TV's of the LCD/PLASMA persuasion which expect VIDEO (limited) levels.... :p

OK. Even if it isn't an overestimate at all, let's put it 90-10% or even 80-20%. Does it change something? Does it change the filters out there that won't be modified and won't work with madVR? Not really.

I don't think you understand the purpose of madVR.

The whole entire point of starting madVR was to do the best job of converting videos from 4:2:0 YUV to 4:4:4 RGB by doing the best chroma (and luma) upsampling possible.

I don't understand why you would want to send it RGB at all, when the main point of madVR is that it does an amazing job of the conversion to RGB, unlike pretty much everything else. (take a look at the second post in this topic)

Where are you getting RGB encoded/full range source material from, or what is your reason for not wanting to send YV12/NV12 to madVR?
It's actually the reason my main computer is a Windows PC and not a Mac now, no joke.

I would probably just be using a Mac and a stand-alone Blu-ray player if it weren't for madVR. (combined with ReClock for DVD)

:rolleyes:

madVR is a video renderer. And it accepts a lot of formats. RGB is one of those formats. There are problems with RGB input. Your point?

If all other renderers don't work like this then all other renderers are doing it wrong

Unless you have information we don't have, that's just another opinion, like madshi's or mine. There is no good or bad way. There's just the way you choose to implement it. And oh boy, madVR does it the way nobody else does, which causes the problems we are discussing.

[tschi]

@madshi : I uncheck "enable automatic fullscreen exclusive mode" and I have a error. I send you the report automatically using "send bug report" button (user name = Pascal, computer = Origen. Nice functionality by the way)

[pirlouy]

Huh ? Where did you see this feature (send bug report)? I'm not sure there's such a thing...

[nevcairiel]

Huh ? Where did you see this feature (send bug report)? I'm not sure there's such a thing...

It shows up automatically in some crash-cases.

[mzso]

delete

[6233638]

madVR is a video renderer. And it accepts a lot of formats. RGB is one of those formats. There are problems with RGB input. Your point?My point is that it's the video renderer's job to handle color space conversion, not the decoder's. (same goes for scaling)

LAV CUVID, ffdshow, CoreAVC etc. should decode the MPEG video to 4:2:0 YUV (ideally YV12/NV12) pass it on, and the renderer then performs chroma/luma upsampling and color space conversions for output to the display.

MadVR was built to do the very best job of converting 4:2:0 YUV to RGB with a high level of precision. What's the point of running madVR if you are telling the decoder to do madVR's job?

Unless your video file is natively RGB (in which case, what is your source?) you should not be sending madVR RGB.

[pirlouy]

Unless you have information we don't have, that's just another opinion, like madshi's or mine. There is no good or bad way. There's just the way you choose to implement it. And oh boy, madVR does it the way nobody else does, which causes the problems we are discussing.
Your point ?
It's blabla and whining. :-)
your zuber point seems to be others do like this so do this !
Even a noob like me with 0 knowledge, I can say that.

Please argue seriously with Madshi. I'm sure you can do better. Remember what Madshi said: he wants to start from the beginning and not copy others ideas.

You have a lot more knowledge than me, but you spend more time whining instead of arguing with sources, links, etc.
Leeperry is not always popular but he gives links which can help him.

Please don't lose time slanging me. I know I'm a loser, noob etc (seriously). :)

[madshi]

Yes, CPU and GPU load are less then 10%.
And with other renderers (overlay, EVR, Haali) everything is ok.
So bottleneck is somewhere in the GPU and not in the raw computing power... And it is related to chroma upsampling (YV12, NV12, YUY2, UYVY -> RGB32 conversion).
Tested b/w video - 0 framedrops.

And another strange thing - in exclusive mode even presentation queue is full (3-4/4).
Number of dropped frame is about the same (1000-1200 out from 9240) at any resolution (from native 1024x576 to desktop 1920x1080) and mode (windowed/exclusive).
Can I have a log from exclusive mode, where frames are dropped although all queues seem to be full?

madvr external filter(lav,dscaler ) problem dvd vob files..(pc and notebook)
deinterlacing problem =http://imageshack.us/photo/my-images/853/ekrntsw.jpg/
ı am back mpeg2 internal codec :(
my english is poor sorry..thanks :)
good work..
madVR doesn't currently support deinterlacing, so you have to deinterlace before sending the video stream to madVR. You can do that by using the ffdshow raw processing filter, or by using the DScaler IVTC Mod MPEG2 decoder, or by using the LAV CUVID decoder (if you have an NVidia card supported by LAV CUVID). I plan to look into deinterlacing in a future madVR version.

There are these little circular spots where you can click called options, that let you configure it the way you want ;)
You can't have it both ways. Either you consider it correct that CoreAVC is always outputting full range RGB, or you are considering it incorrect. If you consider it correct, then people with a TV/projector are screwed with *all* renderers, because they need limited range RGB. If you consider CoreAVC's current behaviour incorrect then you can't complain about madVR producing incorrect output with CoreAVC.

madshi thinks that what the decoder should do is if the input is limited range, output it as limited range. If the source is full range, output is as full range. And then let the renderer do its job and convert that if necessary.
Yes, that's exactly my point of view. And let me give you a pretty good reason for that. Here's a sample video file (thanks leeperry):

http://www.mediafire.com/?wbmyif3yf2mijti

screenshot 1: (http://madshi.net/levelsChange1.png) CoreAVC outputs NV12 (video), madVR converts to RGB (PC)
screenshot 2: (http://madshi.net/levelsChange2.png) ffdshow outputs RGB (video), madVR converts to RGB (PC)
screenshot 3: (http://madshi.net/levelsChange3.png) CoreAVC outputs RGB (PC), madVR displays the result untouched
screenshot 4: (http://madshi.net/levelsChange4.png) ffdshow outputs RGB (PC), madVR displays the result untouched

You see the problem?

Changing levels in 8bit is a very bad idea, and that's what pretty much all decoders are doing. So decoders should please *please* keep levels alone by default.

The problem madshi doesn't seem to fully understand is that all renderers except madVR don't do any conversions to RGB, so if you want proper image with them you have to give them the image fully converted, ready to be displayed.
Why do you say that? You know perfectly well that I understand what you just said. I just believe that all renderers except madVR are misbehaving in this situation.

And 99.9% of users out there have a PC monitor expecting full range RGB, so that is what all known decoders (including CoreAVC) that output RGB do by default, except the future LAV Video if nevcairiel uses the default he said he was going to use.
I've searched for decoders outputting RGB and on a quick check I only found ffdshow, CoreAVC and LAV Video. ffdshow allows you to choose whether RGB is output as full or limited range. CoreAVC seems to have a bug (which you said so yourself, if I understand your posts correctly), and LAV Video is going to leave levels untouched, IIRC. So far I see no preference for full range RGB output at all. Which other decoders are there which offer RGB output?

There is no correct or incorrect, but doing what the majority has been using for ages is the wise decision IMHO. Some filters offer options to control the conversion, like CoreAVC, but others don't, so changing this established behavior will just break things like it is doing now in madVR. All the correctness you may have in your software is useless if the final result is bad.
I agree that the final result counts. Autodetection was just added recently. Give it some time to develop before making a final judgement. You found a bug, provided me with a sample, that's great (thanks), I'll fix that. The CoreAVC bug might get fixed in a future CoreAVC version. LAV Video will definitely get fixed very soon. What problems will remain after that? We'll see soon enough. Hopefully I'll be able to fix them, too. If after trying I'm not able to make things autodetect correctly in 99% of all cases, I might consider adding further options. But first let me try to perfect autodetection. I believe I can make it work much better than you think.

have you considered a “reset video device CLUT during playback“ feature for madVR? It's a hassle to always run a manual script to reset them before playback (and reload afterwards).
I've that on my to do list. I'll increase priority for that.

OK. Even if it isn't an overestimate at all, let's put it 90-10% or even 80-20%. Does it change something? Does it change the filters out there that won't be modified and won't work with madVR? Not really.
From the feedback I'm getting in this thread it seems to me that at least 30% of madVR users have dual monitor setups with a TV/projector as secondary monitor, maybe more. Maybe my impression is wrong, maybe madVR has just more problems with dual monitor setups, which may give me a wrong impression about user numbers, but I'm pretty sure it's much more than 10%. And yes, that definitely changes a lot of things. Dual monitor HTPC users are likely to watch videos sometimes on their PC monitor and sometimes on the secondary monitor. In many cases the secondary monitor will need RGB video levels, while the computer LCD usually needs RGB PC levels. Which means that if madVR would simply passthrough RGB, users would have to switch levels in CoreAVC/LAV Video/whatever, every time they move the media player from primary to secondary monitor or vice versa. That's a usability catastrophe, as I mentioned before.

@madshi : I uncheck "enable automatic fullscreen exclusive mode" and I have a error. I send you the report automatically using "send bug report" button (user name = Pascal, computer = Origen. Nice functionality by the way)
I don't think I received the report, unfortunately. Can you send it again, please?

Huh ? Where did you see this feature (send bug report)? I'm not sure there's such a thing...
It's only available if the settings dialog or tray icon application crashes. I plan to make the feature available if madVR itself crashes, too, in a future version. But that will take some time to implement...

http://i877.photobucket.com/albums/ab339/avada0/screenshot/lav-splitter-many-times.png

This is weird... Its with a blu-ray m2ts file and potplayer.
Don't see the image. Bandwidth exceeded. Please use a better image host.

[STaRGaZeR]

My point is that it's the video renderer's job to handle color space conversion, not the decoder's. (same goes for scaling)

LAV CUVID, ffdshow, CoreAVC etc. should decode the MPEG video to 4:2:0 YUV (ideally YV12/NV12) pass it on, and the renderer then performs chroma/luma upsampling and color space conversions for output to the display.

MadVR was built to do the very best job of converting 4:2:0 YUV to RGB with a high level of precision. What's the point of running madVR if you are telling the decoder to do madVR's job?

Unless your video file is natively RGB (in which case, what is your source?) you should not be sending madVR RGB.

And why do you suppose my source is a decoder? You're missing that some people (specially on this forum) like to filter stuff. Some filters work best with full chroma information, and they output that. Usually RGB, as 4:4:4 YUV formats aren't widely used.

madVR is a lot more than high quality YV12 to RGB conversion. Anyone using it should know that.

Some files are native RGB (like Fraps), some of them are filtered with filters that produce RGB output. But that's really not the point. The point is that RGB input to madVR has issues. Where did this RGB come from is not important.

You have a lot more knowledge than me, but you spend more time whining instead of arguing with sources, links, etc.

If there were links and/or sources, where how to deal with this was set in stone, we wouldn't be having this conversation ;). To the rest of your post, well, I was taught to stay away and listen to stuff I don't understand. I guess some people out there didn't have the same education.

[yesgrey]

Using the non-Microsoft madVR (instead of EVR/VMR), with a non-Microsoft OpenMediaFormat (instead of DXVA_ExtendedFormat), while using Microsoft components to compete against Microsoft in a way that violates the claims of the patent could be justified enough, if they ever felt threatened by madVR's presence or popularity.
If that ever happens, it would be much cheaper and easier to them to buy madVR and rename it to M$VR, and I'm sure madshi wouldn't be too sad... :D

[mzso]

Don't see the image. Bandwidth exceeded. Please use a better image host.

Sorry. I even missed the topic...

[nand chan]

I've that on my to do list. I'll increase priority for that.

It's rather simple, gdi32.dll exports SetDeviceGammaRamp and GetDeviceGammaRamp: http://msdn.microsoft.com/en-us/library/dd372194%28v=vs.85%29.aspx

A “blank” or reset gamma ramp is calculated with output = (input << 8) + input where input is on the scale 0-255 and output on the scale 0-65535.

It's a current subject of debate whether or not to use that formula or simply output = (input << 8), but as far as I can tell the graphics card does not differentiate between the two on 8-bit hardware and all professional color management suites use the former.

Let me know if you have any questions.

If that ever happens, it would be much cheaper and easier to them to buy madVR and rename it to M$VR, and I'm sure madshi wouldn't be too sad... :D

Would the license even permit that?

[ajp_anton]

Bug:
If a subtitle and the "grey OSD" (that shows volume changes and the video timer after a seek) are showing at the same time and you pause the video, the subtitle will disappear.

[QBhd]

From the feedback I'm getting in this thread it seems to me that at least 30% of madVR users have dual monitor setups with a TV/projector as secondary monitor, maybe more. Maybe my impression is wrong, maybe madVR has just more problems with dual monitor setups, which may give me a wrong impression about user numbers, but I'm pretty sure it's much more than 10%. And yes, that definitely changes a lot of things. Dual monitor HTPC users are likely to watch videos sometimes on their PC monitor and sometimes on the secondary monitor. In many cases the secondary monitor will need RGB video levels, while the computer LCD usually needs RGB PC levels. Which means that if madVR would simply passthrough RGB, users would have to switch levels in CoreAVC/LAV Video/whatever, every time they move the media player from primary to secondary monitor or vice versa. That's a usability catastrophe, as I mentioned before.



I am one of those guys. And my setup is blessed since I can select Full RGB on my HD 5770 and there is a Black Level setting on my Plasma to allows my to either use Limited or Full RGB (Low & High settings respectively)... but if I was not so blessed, I would need madVR to behave as madshi intends it. And this behavior would indeed avoid the usability catastrophe :)

QB

ps... oddly enough I just learned that I had my Plasma set up wrong for a long time since I thought the Low Black Level was Full RGB (PC Levels)... videos look much better once I learned of this mistake! :)

[leeperry]

A “blank” or reset gamma ramp is calculated with output = (input << 8) + input where input is on the scale 0-255 and output on the scale 0-65535.

It's a current subject of debate whether or not to use that formula or simply output = (input << 8), but as far as I can tell the graphics card does not differentiate between the two on 8-bit hardware and all professional color management suites use the former.
Which reminds me that pstrip's tech support told me that pstrip could only capture 8bit LUT's, and that it'd require another app to capture them in 16bit: http://forums.entechtaiwan.com/index.php?topic=6332.135;wap2

When using a VGA output, the video is 8bit but the LUT is processed in 10bit, you can even double-check it w/ ArgyllCMS.

[nand chan]

Which reminds me that pstrip's tech support told me that pstrip could only capture 8bit LUT's, and that it'd require another app to capture them in 16bit: http://forums.entechtaiwan.com/index.php?topic=6332.135;wap2

When using a VGA output, the video is 8bit but the LUT is processed in 10bit, you can even double-check it w/ ArgyllCMS.

Well, “8 bit LUT” is just a regular 16 bit LUT, except with the values bit-shifted (and possibly added afterwards, depending on the way his logic handles 8 bit LUTs)

But yeah, I'm guessing the 6 least significant bits are never going to be used in any case because the Radeon chipset itself has 10-bit display drivers only (Edit: Same for GeForce), and I doubt that the driver is going to perform any 16->10 bit dithering.

[ianken]

Just a want to add a thanks to Madshi for his work.

I chuckled when I saw H.264 decoding get gobbled into the project. :-) Now just add integrated subtitles. LOL.

Anyway, keep it up and don't let the self appointed experts get ya down.

[STaRGaZeR]

You can't have it both ways. Either you consider it correct that CoreAVC is always outputting full range RGB, or you are considering it incorrect. If you consider it correct, then people with a TV/projector are screwed with *all* renderers, because they need limited range RGB. If you consider CoreAVC's current behaviour incorrect then you can't complain about madVR producing incorrect output with CoreAVC

There is no correct way with all other renderers. Didn't we agree on this already? All other renderers don't touch the video. You either send them full range or limited range, your choice. The choice all of them made is full range for obvious target user reasons. Some of them offer options to change this default behavior, so they have you covered. But others don't, and that's the problem. For both madVR and TV users.

CoreAVC outputs full range by default, not always. That's what the options are for (they don't work, different issue).

Yes, that's exactly my point of view. And let me give you a pretty good reason for that. Here's a sample video file (thanks leeperry):

http://www.mediafire.com/?wbmyif3yf2mijti

screenshot 1: (http://madshi.net/levelsChange1.png) CoreAVC outputs NV12 (video), madVR converts to RGB (PC)
screenshot 2: (http://madshi.net/levelsChange2.png) ffdshow outputs RGB (video), madVR converts to RGB (PC)
screenshot 3: (http://madshi.net/levelsChange3.png) CoreAVC outputs RGB (PC), madVR displays the result untouched
screenshot 4: (http://madshi.net/levelsChange4.png) ffdshow outputs RGB (PC), madVR displays the result untouched

You see the problem?

Changing levels in 8bit is a very bad idea, and that's what pretty much all decoders are doing. So decoders should please *please* keep levels alone by default.

Why, oh why do you keep trying to convince me about this. I've already told you that I'm with you. The problem are those filters that DON'T do this. Or those that CAN'T do this, for whatever reason.

By the way, none of them look smooth at all here. From best to worst: SS 1 and 2 (no apparent difference) > SS 3 > SS 4. Also, no real life difference here between those options except for CoreAVC horrible nearest neighbor chroma upscaling. I only care about real life.

Why do you say that? You know perfectly well that I understand what you just said. I just believe that all renderers except madVR are misbehaving in this situation.

Me too, but that's the way it is.

I've searched for decoders outputting RGB and on a quick check I only found ffdshow, CoreAVC and LAV Video. ffdshow allows you to choose whether RGB is output as full or limited range. CoreAVC seems to have a bug (which you said so yourself, if I understand your posts correctly), and LAV Video is going to leave levels untouched, IIRC. So far I see no preference for full range RGB output at all. Which other decoders are there which offer RGB output?

I know about those I've used: ffdshow, LAV Video, CoreAVC, Fraps, PowerDVD, Xvid. ffdshow: full range default, with options. LAV Video: future unknown, with options. CoreAVC: full range default, with options (the bug is that it always outputs full range regardless of your selection). Fraps: full range default, no options. PowerDVD: no options, can't remember and I don't have it anymore, but probably full range too. Xvid: full range default, no options. I'd call that a preference for full range. Not to mention Avisynth output from ffdshow, endless possibilities.

Put yourself in this situation: you have native full range content being output from one of those filters that don't and won't use DXVA_ExtendedFormat. Do you want to convert it to limited range, then to full range again in the renderer? Or even worse, no DXVA_ExtendedFormat and no options, so guaranteed unneeded expansion with current madVR. Solution?

I agree that the final result counts. Autodetection was just added recently. Give it some time to develop before making a final judgement. You found a bug, provided me with a sample, that's great (thanks), I'll fix that. The CoreAVC bug might get fixed in a future CoreAVC version. LAV Video will definitely get fixed very soon. What problems will remain after that? We'll see soon enough. Hopefully I'll be able to fix them, too. If after trying I'm not able to make things autodetect correctly in 99% of all cases, I might consider adding further options. But first let me try to perfect autodetection. I believe I can make it work much better than you think.

Good luck with that, even if I think you won't succeed. The funny part is that you are going to think your autodetection is perfect until someone comes with a problem, showing that it wasn't perfect. And if you fix that, the same thing again. In the meantime, or forever, we are stuck without options.

From the feedback I'm getting in this thread it seems to me that at least 30% of madVR users have dual monitor setups with a TV/projector as secondary monitor, maybe more. Maybe my impression is wrong, maybe madVR has just more problems with dual monitor setups, which may give me a wrong impression about user numbers, but I'm pretty sure it's much more than 10%. And yes, that definitely changes a lot of things. Dual monitor HTPC users are likely to watch videos sometimes on their PC monitor and sometimes on the secondary monitor. In many cases the secondary monitor will need RGB video levels, while the computer LCD usually needs RGB PC levels. Which means that if madVR would simply passthrough RGB, users would have to switch levels in CoreAVC/LAV Video/whatever, every time they move the media player from primary to secondary monitor or vice versa. That's a usability catastrophe, as I mentioned before.

30% of monitor+TV users in this thread. You do know the kind of people that are in this thread. If there's only 30% here, out there the % is probably a lot less than 0.1%. The average joe in your mind sure is a lot less average than the real average joe that installs codec packs or uses VLC :D. But we'll never know and this is irrelevant to the topic anyway.

I have never asked you to pass RGB untouched. I've asked you to add options for that, default to what you feel it's best. And since you have separate options for each display this wouldn't be a problem at all with dual monitor setups.

[leeperry]

It seems to me that someone missed the memo that you can create a "force full range input" folder in mVR's folder, and there won't be any need to act as a drama queen anymore.

[pirlouy]

Yes, madVR desperately needs a wiki. :/
If you miss one page here, you can miss this option (force full range input file). With an help page, it would not be a problem and would allow to avoid "I have MPC-HC 64 bits, I don't understand" kind of stuff.

[STaRGaZeR]

It seems to me that someone missed the memo that you can create a "force full range input" folder in mVR's folder

Someone missed the consequences of doing so: everything is considered full range, not only RGB.

[vivan]

Can I have a log from exclusive mode, where frames are dropped although all queues seem to be full?http://www.mediafire.com/?8co2m4pls56xdnk
Errors are "00003434 Upload drop frame 153, no free vsync slot, plannedVSync: 185"
http://firepic.org/images/2011-08/3qjz4bmuwlxem1q51w3qaqdzd.png

So I have installed ReClock. And even if I choose "Orginal Speed" there are no dropped frames...

[leeperry]

Oops, I forgot to mention that I also get the Avisynth stuttering right when playback starts sometimes, and I have to reseek to have it smooth. Maybe it's a problem in ffdshow, but if it's in mVR...this would be really great to have it fixed if any possible :)

Here are some logs when it starts to hiccup right away: mVR74 avisynth.rar (http://www.mediafire.com/?q4q8afs5vrairq7)

checking the option to delay playback until the queue is full fixes the problem completely, but it doesn't change anything to the stutter when I do realtime Avisynth script changes(like in the log I previously provided). I think it would be great to have a "only when playback starts" sub-option to the "delay playback until queue is full" feature if any possible please.

:thanks:

[cyberbeing]

BUG: Distorted output with madVR internal decoder when playing back a MKV with cropping flags specified.

[TheShadowRunner]

Hi Madshi,
I would like to report 1 nasty bug that makes madVR pretty much unusable with ReClock's RunEvent feature, and a small cosmetic request.

The bug:
On XP SP3, I use ZP + Reclock 1.8.7.7 with ReClock's Runevent feature enabled. It changes the screen resolution/frequency according to media type.
When starting a 1080p movie playback, Reclock's Runevent switches my default resolution from 1280x720@60hz to 1920x1080@24hz; this works fine with all renderers (VMR, Haali, EVR).
But with madVR (0.74) in Fullscreen Exclusive Mode, it crashes 90% of the time. (crash in madvr.ax)

The cosmetic request:
Is it possible for you to add a toggle button "Show/Hide OSD" on the filter's property page (http://videoff7.free.fr/madreq.jpg)? the reason is I don't always have a keyboard handy (htpc) for Ctrl+J ^_^;;

Thanks,

TSR
Edit: the reason I use ReClock's RunEvent over madVR's "list all display modes madVR may switch to" is flexibility. With RunEvent, I set SD/720p media (source height < or = 720) to be displayed at 1280x720@24, 50 or 60. And for 1080p media (source height > 720), RunEvent will switch the display to 1920x1080@24, 50 or 60. In other words, because currently madVR doesn't take source height into account for its display mode switching, only framerate. If madVR could accept "720p24, 720p50, 720p60, 1080p24, 1080p50, 1080p60" in the "list of display modes it may switch to" and use source height to dermine which to use automatically, that would actually be fantastic and I could say farewell to RunEvent.

[leeperry]

BTW, there's no way to choose what algorithm to use for chroma downscaling apparently? so what happens to the chroma when feeding 1080p RGB32 to mVR downscaled to 720p :confused:

[6233638]

BTW, there's no way to choose what algorithm to use for chroma downscaling apparently? so what happens to the chroma when feeding 1080p RGB32 to mVR, downscaled to 720p then :confused:With the new chroma scaling implemented a few months back, I imagine it's scaled up to match the Luma resolution using your chosen method, and both are then downscaled using your Luma downscaling selection.

[leeperry]

Oh yah, and I'm pretty impressed by chroma upsampling via Spline64 in Avisynth, why did you limit Spline to 3 or 4 taps in mVR? Apparently 16 is 4 taps, why no 36 and 64 then? I have to admit that I prefer downscaling in mVR using 3 taps instead of 4, though...so that's merely a question :o

[nand chan]

BTW, there's no way to choose what algorithm to use for chroma downscaling apparently? so what happens to the chroma when feeding 1080p RGB32 to mVR downscaled to 720p :confused:

It may just use the chroma algorithm to downscale as well, I don't know.

It's not really an issue since most content out there is subsampled with 4:2:0 so you're going to upscale chroma even on 1080p content.

[Superb]

Alright... Here's a new small bug report (madVR 0.74). It has to do w/ a secondary monitor scenario.

...Thanks, will look at this later.Just wondering if you had time to look at the log... :)

[ajp_anton]

Oh yah, and I'm pretty impressed by chroma upsampling via Spline64 in Avisynth, why did you limit Spline to 3 or 4 taps in mVR? Apparently 16 is 4 taps, why no 36 and 64 then? I have to admit that I prefer downscaling in mVR using 3 taps instead of 4, though...so that's merely a question :oI'm pretty sure that taps=3 is 36 and taps=4 is 64.

[cyberbeing]

<mp4_guy> anyway, in my experience, 3 taps is almost always visually optimal assuming a large downscale and a good quality source
<Dark_Shikari> spline36 is a lot more than 3 taps
<mp4_guy> no, its 3 taps
<Dark_Shikari> lanczos3 is 3 taps
<Dark_Shikari> spline36 is 4
<mp4_guy> yes it is
<mp4_guy> no, 64 is 4 taps
<Dark_Shikari> oh, you're measuring taps that way
<mp4_guy> wha?
<Dark_Shikari> by that logic, h264's tapfilter is 3-tap
<mp4_guy> yeah
<mp4_guy> it is
<Dark_Shikari> I call it 6-tap
<mp4_guy> general convention dows not count the zeroes as taps
<Dark_Shikari> er, I'm not counting zeroes
<mp4_guy> er nm, I meant the mirrored coefs
<Dark_Shikari> well, talk to the ITU
<Dark_Shikari> they call it 6-tap
There are just two different way of counting taps.
I've always assumed madshi was counting taps as mp4_guy did in the above, which does make 3 taps = Spline36 and 4 taps = Spline64.

[madshi]

It's rather simple, gdi32.dll exports SetDeviceGammaRamp and GetDeviceGammaRamp: http://msdn.microsoft.com/en-us/library/dd372194%28v=vs.85%29.aspx

A “blank” or reset gamma ramp is calculated with output = (input << 8) + input where input is on the scale 0-255 and output on the scale 0-65535.

It's a current subject of debate whether or not to use that formula or simply output = (input << 8), but as far as I can tell the graphics card does not differentiate between the two on 8-bit hardware and all professional color management suites use the former.
Thx, will keep that in mind.

Bug:
If a subtitle and the "grey OSD" (that shows volume changes and the video timer after a seek) are showing at the same time and you pause the video, the subtitle will disappear.
That's a known problem. It's not easy for me to fix without compromising on performance.

Now just add integrated subtitles. LOL.
On my list of things to eventually look into... :)

http://www.mediafire.com/?8co2m4pls56xdnk
Errors are "00003434 Upload drop frame 153, no free vsync slot, plannedVSync: 185"
http://firepic.org/images/2011-08/3qjz4bmuwlxem1q51w3qaqdzd.png

So I have installed ReClock. And even if I choose "Orginal Speed" there are no dropped frames...
I'll look into that.

Oops, I forgot to mention that I also get the Avisynth stuttering right when playback starts sometimes, and I have to reseek to have it smooth. Maybe it's a problem in ffdshow, but if it's in mVR...this would be really great to have it fixed if any possible :)

Here are some logs when it starts to hiccup right away: mVR74 avisynth.rar (http://www.mediafire.com/?q4q8afs5vrairq7)

checking the option to delay playback until the queue is full fixes the problem completely, but it doesn't change anything to the stutter when I do realtime Avisynth script changes(like in the log I previously provided). I think it would be great to have a "only when playback starts" sub-option to the "delay playback until queue is full" feature if any possible please.
The new logs may help cause the problem is right at the start.

BUG: Distorted output with madVR internal decoder when playing back a MKV with cropping flags specified.
I've tried, but I can't reproduce that here. Did you test with v0.74? Cause I fixed a distortion bug in v0.74 (compared to v0.73). If you can reproduce it with v0.74, please upload a small sample - thanks!

I would like to report 1 nasty bug that makes madVR pretty much unusable with ReClock's RunEvent feature, and a small cosmetic request.

The bug:
On XP SP3, I use ZP + Reclock 1.8.7.7 with ReClock's Runevent feature enabled. It changes the screen resolution/frequency according to media type.
When starting a 1080p movie playback, Reclock's Runevent switches my default resolution from 1280x720@60hz to 1920x1080@24hz; this works fine with all renderers (VMR, Haali, EVR).
But with madVR (0.74) in Fullscreen Exclusive Mode, it crashes 90% of the time. (crash in madvr.ax)
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. I do plan to rewrite the display mode changer to make it more powerful in a future version.

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.

The cosmetic request:
Is it possible for you to add a toggle button "Show/Hide OSD" on the filter's property page (http://videoff7.free.fr/madreq.jpg)? the reason is I don't always have a keyboard handy (htpc) for Ctrl+J ^_^;;
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.

With the new chroma scaling implemented a few months back, I imagine it's scaled up to match the Luma resolution using your chosen method, and both are then downscaled using your Luma downscaling selection.
Correct.

I'm pretty sure that taps=3 is 36 and taps=4 is 64.
Correct.

There are different ways to count taps (see cyberbeing's IRC log). Marketing departments like to increase numbers artificially. I prefer the scientific approach.

[madshi]

CoreAVC outputs full range by default, not always. That's what the options are for (they don't work, different issue).
I'm not sure about CoreAVC's default output. The default CoreAVC setting is "Auto detect". Whether that will be PC levels or TV levels or "passthrough" is hard to say due to the current bug which always outputs PC levels. I've asked BetaBoy to not touch the levels by default and to fill DXVA_ExtendedFormat, and it seems Core might be doing just that in a future version (but not in the initial 3.0).

Why, oh why do you keep trying to convince me about this. I've already told you that I'm with you. The problem are those filters that DON'T do this. Or those that CAN'T do this, for whatever reason.
Then I misunderstood you. I thought you were advertizing decoders to always output PC levels. So we're on the same page? We both would like decoders to not do any levels conversion (by default), and to fill DXVA_ExtendedFormat?

By the way, none of them look smooth at all here. From best to worst: SS 1 and 2 (no apparent difference) > SS 3 > SS 4. Also, no real life difference here between those options except for CoreAVC horrible nearest neighbor chroma upscaling. I only care about real life.
I do think that the really obvious banding in SS 3 and SS 4 would be visible in real life, too. I've found real life scenes with a log of fog to behave similar to grayscale ramps sometimes.

I know about those I've used: ffdshow, LAV Video, CoreAVC, Fraps, PowerDVD, Xvid. ffdshow: full range default, with options. LAV Video: future unknown, with options. CoreAVC: full range default, with options (the bug is that it always outputs full range regardless of your selection). Fraps: full range default, no options. PowerDVD: no options, can't remember and I don't have it anymore, but probably full range too. Xvid: full range default, no options. I'd call that a preference for full range.
My list looks a bit different: ffdshow full range default. LAV Video: probably passthrough default (not sure), but definitely not full range, according to nevcairiel's posts. CoreAVC: Currently output levels bug, future unsure, hopefully passthrough. Fraps: full range by default, and that makes a lot of sense since Fraps is native full range content. You could also classify Fraps as "passthrough". PowerDVD: unknown. Xvid: full range.

Put yourself in this situation: you have native full range content being output from one of those filters that don't and won't use DXVA_ExtendedFormat. Do you want to convert it to limited range, then to full range again in the renderer? Or even worse, no DXVA_ExtendedFormat and no options, so guaranteed unneeded expansion with current madVR. Solution?
The solution would be for madVR to automatically detect that the filter outputs PC levels and to handle it accordingly. Internal PC -> TV -> PC levels conversion is not a problem because it's done in 32bit floating point per component (96bit per pixel).

How about this: You have native full range content (e.g. FRAPS) and you have a display which wants TV levels. How to solve that? Your wish to have madVR passthrough RGB untouched wouldn't help here.

Or how about this: You're using a number of different decoders, some of which output full range RGB (no options), while others output limited range RGB (no options). How to solve that?

Good luck with that, even if I think you won't succeed. The funny part is that you are going to think your autodetection is perfect until someone comes with a problem, showing that it wasn't perfect. And if you fix that, the same thing again. In the meantime, or forever, we are stuck without options.
My ultimate solution (for some future version) is to have autodetection work as well as possible, and to allow the user to manually specify which filter is delivering which RGB levels. The latter would allow users to "repair" autodetection, in case it fails. Would that satisfy your needs?

This manual overwriting is planned for a future version, though. For now I'd like to make autodetection work well enough first.

What I can say right now is that it should be easy for me to make ffdshow, LAV Video, CoreAVC and Fraps work without issues, with RGB output. Other filters might have to be added support for one by one.

I have never asked you to pass RGB untouched. I've asked you to add options for that, default to what you feel it's best. And since you have separate options for each display this wouldn't be a problem at all with dual monitor setups.
The problem is that I don't think passing RGB through untouched will help much. If madVR's autodetection works, passthrough is not needed. If madVR's autodetection fails, passthrough would help in some cases, but not in all. I think better than passthrough would be an option to allow users to tell madVR which decoder is outputting which RGB levels (see above). That should really solve *all* problems.

[cyberbeing]

I've tried, but I can't reproduce that here. Did you test with v0.74? Cause I fixed a distortion bug in v0.74 (compared to v0.73). If you can reproduce it with v0.74, please upload a small sample - thanks!.

Yes, this is with v0.74. Looking into it further, it only seems to happen on first load when using the madVR refresh-rate changer.

1) Load MKV with cropping flags.
2) madVR changes refresh rate.
3) Video is distorted.
4) Reload video without closing MPC-HC or changing refresh.
5) Video is no longer distorted.

It happens with all cropped MKVs (just re-mux anything with mmg with cropping flags like 8,8,8,8), but if you still need a sample I could upload one.

Here is a log: http://www.mediafire.com/?tudseazrx074zw6
Opened Video
madVR Refresh Rate Changer activates.
10 seconds distorted playback.
Paused 10 seconds.
Reloaded Video.
10 seconds of normal playback.
Closed MPC-HC.

This is on WinXP SP3 x86 w/ an NVIDIA GPU.

[leeperry]

The new logs may help cause the problem is right at the start.
Well, that's what I thought too..but it's a problem of the buffer not being filled fast enough I guess, so maybe it's the same story when doing realtime AVS script changes, not sure. It might be that ffdshow stutters a bit when I do that, but then I don't understand why a reseek fixes the problem right away...but still, I guess ffdshow is the problem more than mVR :o

It may just use the chroma algorithm to downscale as well, I don't know.

It's not really an issue since most content out there is subsampled with 4:2:0 so you're going to upscale chroma even on 1080p content.
Maybe I've got it wrong, but I think YUY2 samples chroma once in every 2 pixels in a row, YV12 samples chroma once in every 2x2 pixel block...but RGB32 has a fully upscaled chroma to the same resolution as luma AFAIK? So when feeding 1080p RGB32 and asking mVR to downscale to 720p, it's indeed got to downscale chroma...and atm, I'm wondering what algorithm is used considering that mVR's GUI doesn't offer a choice for chroma downscaling.

There are just two different way of counting taps.
I've always assumed madshi was counting taps as mp4_guy did in the above, which does make 3 taps = Spline36 and 4 taps = Spline64.
Oh, that makes sense!

[nevcairiel]

Maybe I've got it wrong, but I think YUY2 samples chroma once in every 2 pixels in a row, YV12 samples chroma once in every 2x2 pixel block...but RGB32 has a fully upscaled chroma to the same resolution as luma AFAIK? So when feeding 1080p RGB32 and asking mVR to downscale to 720p, it's indeed got to downscale chroma...and atm, I'm wondering what algorithm is used considering that mVR's GUI doesn't offer a choice for chroma downscaling.

Chroma Upscaling is used to convert the Chroma from 4:2:0 or 4:2:2 to 4:4:4. RGB is already 4:4:4, so there is no need to upscale the chroma.
Note that the chroma upscaling does not actually change the resolution of the image yet, it just brings the subsampled chroma to the same resolution as the luma.

After the Chroma was upscaled, the whole image is processed with the Luma algorithm, be it up or downscaling, there is no separate algorithm for luma/chroma. Using different algorithms for chroma here would probably have the possibility of some odd results, as well as alot of added complexity.

At least, thats how i understood the processing chain.

[leeperry]

RGB is already 4:4:4, so there is no need to upscale the chroma.
Which is my point.
After the Chroma was upscaled, the whole image is processed with the Luma algorithm, be it up or downscaling, there is no separate algorithm for luma/chroma. Using different algorithms for chroma here would probably have the possibility of some odd results
I don't see why? And I realize that RGB input support in mVR is a very recently added feature, so its config panel is still very much YCbCr oriented, not allowing to choose what algorithm to choose for chroma downscaling. Personally I'd like to try spline3 for luma downscaling and softcubic70/80 for chroma downscaling, but this is not currently possible I'm afraid. How about making the "chroma upscaling" algorithm also used for downscaling? that would require minimal GUI changes :)

[nevcairiel]

And I realize that RGB input support in mVR is a very recently added feature, so its config panel is still very much YCbCr oriented, not allowing to choose what algorithm to choose for chroma downscaling.

There is no difference what input format is used. If the image needs to be downscaled, YUV chroma also needs to be downscaled, after being upscaled.
It pretty much always worked like that.

If its even possible to use a different algorithm for the chroma in the final scaling operation, only madshi can say. Although i can imagine that the response might be something thats disappointing to you.

[madshi]

It's just as nevcairiel says. Basically madVR first converts everything to RGB, doing chroma upsampling (if necessary) + color conversion etc. If any up- or downscaling needs to be done, it's done on the RGB data, using the luma algorithms. Maybe I should rename the algorithms from "Luma" to "RGB" or to "image" or whatever.

[leeperry]

right! I guess luma/chroma aren't discrete anymore in RGB indeed, silly me :rolleyes:

[leeperry]

BTW, while you're working on auto-detection from ffdshow, it might be good to detect MPEG1 in order to use the right chroma placement? I've cut/pasted some help files from tritical here: http://forum.doom9.org/showpost.php?p=1522204&postcount=234

I've made an automatic ffdshow profile for the "MPG1" FOURCC in order to ensure proper chroma placement :)

[nand chan]

Chroma Upscaling is used to convert the Chroma from 4:2:0 or 4:2:2 to 4:4:4. RGB is already 4:4:4, so there is no need to upscale the chroma.
Note that the chroma upscaling does not actually change the resolution of the image yet, it just brings the subsampled chroma to the same resolution as the luma.

After the Chroma was upscaled, the whole image is processed with the Luma algorithm, be it up or downscaling, there is no separate algorithm for luma/chroma. Using different algorithms for chroma here would probably have the possibility of some odd results, as well as alot of added complexity.

At least, thats how i understood the processing chain.

I don't quite understand the reason for this, why not upscale both to screen resolution in one go, instead of first making them match?

The way I'd do it is 1. upscale both luma/chroma to screen resolution 2. convert to RGB, 3. run through 3dlut/gamma/other corrections, 4. pull up levels if needed and 5. dither down to screen depth.

What's the motive for converting to RGB before upscaling?

[iSunrise]

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.

[STaRGaZeR]

I'm not sure about CoreAVC's default output. The default CoreAVC setting is "Auto detect". Whether that will be PC levels or TV levels or "passthrough" is hard to say due to the current bug which always outputs PC levels. I've asked BetaBoy to not touch the levels by default and to fill DXVA_ExtendedFormat, and it seems Core might be doing just that in a future version (but not in the initial 3.0).

Try it, I did before posting. Everything in "Auto detect" works as I said. I agree with that, but that's how things are. You know how Core handles bug reports or new features. They have had reproducible, concrete bug reports and missing features for years without being fixed. So I expect a "fix" or DXVA_ExtendendFormat support somewhere in the next 5 years :p

Then I misunderstood you. I thought you were advertizing decoders to always output PC levels. So we're on the same page? We both would like decoders to not do any levels conversion (by default), and to fill DXVA_ExtendedFormat?

Absolutely. What's there not to love? Specially the new structure. However not all renderers are as good as madVR, so that's not necessarily a good thing.

I do think that the really obvious banding in SS 3 and SS 4 would be visible in real life, too. I've found real life scenes with a log of fog to behave similar to grayscale ramps sometimes.

I do see banding in the first 2 too, but with the "steps" a lot less defined. I haven't seen any banding in real life content that wasn't on the source already. Unless you use something like deband that banding is there to stay.

The solution would be for madVR to automatically detect that the filter outputs PC levels and to handle it accordingly. Internal PC -> TV -> PC levels conversion is not a problem because it's done in 32bit floating point per component (96bit per pixel).

How about this: You have native full range content (e.g. FRAPS) and you have a display which wants TV levels. How to solve that? Your wish to have madVR passthrough RGB untouched wouldn't help here.

Or how about this: You're using a number of different decoders, some of which output full range RGB (no options), while others output limited range RGB (no options). How to solve that?

Yep, that wouldn't work. But that never worked anyway. Ideally your autodetect feature should detect this, and act accordingly. Remember the passthru option I propose should be there as backup, for compatibility, not in place of autodetection. Like all those decoders that offer options, they have a default that they consider good and optimal and then options for special cases.

My ultimate solution (for some future version) is to have autodetection work as well as possible, and to allow the user to manually specify which filter is delivering which RGB levels. The latter would allow users to "repair" autodetection, in case it fails. Would that satisfy your needs?

This manual overwriting is planned for a future version, though. For now I'd like to make autodetection work well enough first.

What I can say right now is that it should be easy for me to make ffdshow, LAV Video, CoreAVC and Fraps work without issues, with RGB output. Other filters might have to be added support for one by one.

Of course. Like I said above, I agree autodetection is the best default. But as there will always be exceptions, add options to be able to fix them. RGB passthru is one, settings for each filter is another (not mutually exclusive BTW). In the end that's what every filter with options does. madVR shouldn't be different. What I don't understand is why do you want to make autodetection better before adding the options. Why not add them at the same time you work on autodetection, or even earlier? Options make debugging way easier.

The problem is that I don't think passing RGB through untouched will help much. If madVR's autodetection works, passthrough is not needed. If madVR's autodetection fails, passthrough would help in some cases, but not in all. I think better than passthrough would be an option to allow users to tell madVR which decoder is outputting which RGB levels (see above). That should really solve *all* problems.

The problem I see with that option you propose is that the same decoder may not output the same levels all the time, needing you to reconfigure stuff and having bad levels until you notice (if you notice). Not to mention the need to properly configure madVR for those decoders that need it at least once. This sounds also way more complex. But as said above, why not both? Fine control is always better.

[6233638]

I don't quite understand the reason for this, why not upscale both to screen resolution in one go, instead of first making them match?From my testing, Bicubic 75 produces the best "match" between chroma and luma when viewed at 1:1. By that, I mean the least amount of color bleeding out the edges, avoiding as much ringing as possible etc.
I then use SoftCubic 70 for luma upscaling as my preferred algorithm because it keeps aliasing and ringing very low. (I prefer that to a "sharp" image that adds ringing and/or aliasing to the picture, which I find to be distracting)

If you treat chroma/luma as completely separate entities with their own scaling to the display resolution, you can end up with a mis-match between the two.


For example, with a 1080p video on a 1080p screen, Bicubic 75 would be the correct choice, as it makes chroma match luma very well, and luma is left alone.

With a DVD, where both chroma and luma need to be scaled up to 1080p, scaling the chroma to 1080p with Bicubic 75, and luma to 1080p with SoftCubic 70 are not a good match at all.


But if you scale chroma so that it is a good match for the native luma resolution, and then scale the two up/down with your selected luma algorithm, they stay a good match regardless of input/output resolution.

I do see banding in the first 2 too, but with the "steps" a lot less defined. I haven't seen any banding in real life content that wasn't on the source already. Unless you use something like deband that banding is there to stay.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)

[madshi]

BTW, while you're working on auto-detection from ffdshow, it might be good to detect MPEG1 in order to use the right chroma placement?
Yes, that might make sense. Will add that to my to do list, but not with a high priority.

I don't quite understand the reason for this, why not upscale both to screen resolution in one go, instead of first making them match?
That's what older madVR versions did. Recently I've changed that and feedback has been quite positive. Several people noticed a visible improvement.

The reason is that the ideal algorithm for chroma upsampling is (IMHO) a rather soft one, while most people seem to prefer a rather sharp algorithm for luma/RGB up-/downscaling. If you upsample chroma all the way to the target resolution, chroma becomes a bit too soft, especially for SD content. Remember, if you upscale e.g. 720x480 to 1920x1080, the chroma upscaling is actually 360x240 to 1920x1080. If you scale from 360x240 to 1920x1080 with a very soft chroma upscaling algorithm, chroma becomes too soft. So madVR upscales chroma to match the luma resolution, and then scales everything to the target resolution with the sharper luma algorithm.

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.
Will check if I can reproduce that.

What I don't understand is why do you want to make autodetection better before adding the options. Why not add them at the same time you work on autodetection, or even earlier?
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.

The problem I see with that option you propose is that the same decoder may not output the same levels all the time, needing you to reconfigure stuff and having bad levels until you notice (if you notice). Not to mention the need to properly configure madVR for those decoders that need it at least once. This sounds also way more complex.
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.

From my testing, Bicubic 75 produces the best "match" between chroma and luma when viewed at 1:1. By that, I mean the least amount of color bleeding out the edges, avoiding as much ringing as possible etc.
I then use SoftCubic 70 for luma upscaling as my preferred algorithm because it keeps aliasing and ringing very low. (I prefer that to a "sharp" image that adds ringing and/or aliasing to the picture, which I find to be distracting)
JYMI, did you had the chance to rerun your chroma tests with the new madVR logic yet?

[iSunrise]

Just like 6233638, for the older madVR releases, I have always prefered Bicubic75, because it looked true to the source, without softening too much or adding too much visible ringing. Bicubic75 also worked very well with luma downscaling.

Yesterday I had some time to play around with the settings again and I must say I´m unsure what I´m seeing now. Now it looks like Nearest neighbour for chroma and Bicubic50 for luma upscaling actually looks most true to the source, because it keeps the sharpness intact and doesn´t hide any source information, while not adding any visible aliasing. FYI, with the old algorithm, this looked horrible.

I always use a recorded SD video from the first turrican video game, because it reveals every color, brightness or sharpness change, since you can see every pixel in that video and it has a lot of colors, where you can instantly make out the changes.

To my surprise, it also works _very well_ for movies.

You can download it here:
http://recordedamigagames.ath.cx/modules/tinycontent/index.php?id=531

Personally, I want to avoid smoothing out or hide source information at all costs.

@6233638: I would be interested in your input as well.

[nevcairiel]

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.