madVR - high quality video renderer (GPU assisted)

[e-t172]

Many thanks madshi for this huge changelog :)

Anyway, I have some questions too:
- In "properties", "the display itself is calibrated to the following primaries / gamut", there is no sRGB option. Why? Some displays are calibrated for sRGB (e.g. PC monitors), not video standards.
- How do I know what the "native display bitdepth" is? I have a PC monitor with a TN panel, I'm assuming it is something like 6-7 bit, is there any way to know for sure? Also, what difference does it make?
- If I use an external 3dlut file for calibration, how does it interact with the options in the "properties" tab? Are the options in this tab disabled when using a 3dlut file? If they are, it would probably be best to make it known to the user, as it is quite confusing.
- In "color & gamma", "desired display gamma / transfer function", the default is "pure power curve". Wouldn't "BT.709/601 curve" be a better option, considering that's how video files are supposed to be encoded?

[leeperry]

madVR v0.62 now let's you specify what color standard your display was calibrated to (default is BT.709, leave it at that if you're not sure).
If you mean primaries, it might be a good idea to rename them IMHO(and provide a hotkey to swap between them on the spot http://forum-images.hardware.fr/images/perso/ubik75.gif):
BT.709(HD) = HDTV gamut
BT.601(SD) = SMPTE-C gamut
PAL = EBU gamut

Dumbing down those names will only make things more confusing to everyone I think...as we're talking about gamuts, and there's no 601/PAL gamut.

We'd still need BT.601 transfer function coeffs instead of the default BT.709 for upscaled SD(and that's where the automatic detection from ffdshow would rock). Still, you may wanna clear all this up IMHO...as the ppl who'll be messing w/ these options know what they're dealing w/.

[oddball]

The seekbar still appears on the display showing the video when moving the mouse pointer to the bottom of the display NOT showing the video. Can we please have that fixed in 0.63? Pretty please?

[madshi]

I messed around with 3dlut for a bit since I own an i1Display2 LT and calibrated my plasma with colorHCFR, but since my meter is not the most accurate and the values/readings can vary a bit, I figured the benefit will not be that worthwhile in my case. The main reason I wanted to use it was for gamma boost, since my display has no gamma adjustment options and with yCMS I could boost the gamma closer to 2.22 from my sets 1.87

So basically with the new changes we only need to setup an hd 3dlut file and that will handle both the SD and HD conversions?
You will only need one 3dlut file, anymore. The one 3dlut file will cover NTSC, HD and PAL, with video and PC levels. The most comfortable way would be to let madVR create that 3dlut file for you. For that just on the "calibration" tab tell madVR to calibrate your display by using yCMS, then in the new "yCMS" tab edit the gamut and grayscale measurements and copy&paste the sections from your 3dlut configuration script there. The madVR settings dialog should accept the copy&paste directly.

if my display is 16.7 million (6-bit + AFRC), then 8-bit should be chosen?
If your display is less than 8bit then configuring madVR accordingly should improve image quality for you. Practically it should noticeably reduce banding artifacts. I'd suggest using the "madTestPatternSource" filter with the supplied test patterns (especially colors.ytp) to find out which bitdepth settings works best for you. Set it as low as necessary to make the test patterns look good. Don't go lower than necessary, though, because that will increase visible noise.

- display calibration. Gamut BT.709(HD), looks like a default
- display calibration. Gamma / transfer function - pure power curve / 2.20? Is this again a default setting ( correct setting )?
- color and gamma. Desired pure power curve / 2.20? Default?
These are the default settings. If you don't know what your display is calibrated to then simply leave the settings in the "properties" page at default. You can play with the "desired xxx" values, though. Maybe modifying them will improve image quality for you, depending on which kind of gamma response your display has. The "desired xxx" settings can also be switched via keyboard shortcuts (see changelog).

For some reason, my SD rips look better, even my wife noticed!
Interesting! Can you describe in which way it looks better? There should be a small improvement due to "gamut correction" (see my post with that title for more information), but I wouldn't have expected the improvement to be noticeably by "the wife"... :p

Two bugs from before...
- dual mon, playback on second mon, if I drag the mouse down to the bottom on the first mon, the seek bar shows
- dual mon, playback on second mon, Windows Key takes madVR out of FSE.
Yes, I'm aware of that. Didn't want to delay v0.62 any longer, the changelog was already so big... :)

OMG, the changes list is giving headaches
There should be several things in there you should like... :)

I'll run many tests again, but I'm afraid to really need that "upload frames in render thread" option on my XPSP3/8800GS combo :o
I'm still waiting for some clarifications on that topic. But your emails weren't very helpful in that regard.

I'm getting a crash with MC16. It is reproducible, but I think it might be jRiver's issue....

DUal mon
Play movie on second mon, using the Windows Task bar, using the MC icon hover control, stop the movie.
MC crashes in module madVR_unload

Can't get MPC-HC working right now, will try with it too.
That sounds like a crash in MC. Which doesn't necessarily mean it's MC's fault. But since the crash is in their module, they're in a better position to debug it.

It's really about time I get my display calibrated, so maybe this will press me to get that done.
Not sure if I would hire a calibrator right now. Maybe it would make sense to wait for madVR v1.0. There might still be bugs right now. Or there might come new features helping with calibration.

I recently started using an HTPC on my 1280x720 plasma in the bedroom, and was wondering if someone could recommend an algorithm for luma downscaling? I know everyone has their own preferences, but I'm just not sure where to start.
It's all a matter of taste. Trust your eyes.

- In "properties", "the display itself is calibrated to the following primaries / gamut", there is no sRGB option. Why? Some displays are calibrated for sRGB (e.g. PC monitors), not video standards.
I'll ask yesgrey about that, he's the "expert" in that area.

- How do I know what the "native display bitdepth" is? I have a PC monitor with a TN panel, I'm assuming it is something like 6-7 bit, is there any way to know for sure? Also, what difference does it make?
Telling madVR that your display is 7bit means that madVR applies a twice as high dither strength to make sure you get no banding artifacts. See this post a couple comments above for some recommendations about this topic.

- If I use an external 3dlut file for calibration, how does it interact with the options in the "properties" tab? Are the options in this tab disabled when using a 3dlut file? If they are, it would probably be best to make it known to the user, as it is quite confusing.
Yes, if you calibrate with an external 3dlut file or with the integrated yCMS GUI the gamut and gamma options in the "properties" tab are ignored. I should probably gray them out in this situation.

- In "color & gamma", "desired display gamma / transfer function", the default is "pure power curve". Wouldn't "BT.709/601 curve" be a better option, considering that's how video files are supposed to be encoded?
This has been a long standing discussion. My personal opinion is that by far most ISF calibrators are calibrating displays to a pure power curve. CRTs have a pure power curve, too. Poynton agrees with this. One common opinion is that the BT.709 gamma curve was used mainly to hide sensor noise and that the display is not *supposed* to use a BT.709 gamma curve, too. I believe that makes a lot of sense since BT.601 and BT.709 were created when we only had CRTs which always had a pure power response. Some people have a different opinion, though. So the choice is yours. But the default is the same for the "properties" and "color & gamma" tabs so that with the default settings madVR doesn't do any gamma changes. I think it would be a bad idea to have the default settings make madVR modify gamma in any way.

Anyway, play around with the "desired" gamma settings and let me know which you prefer. There are keyboard shortcuts to change these settings on the fly (see changelog).

[alph@]

madshi, i have this,in avi uncompressed ,I hope it's good. http://www.mediafire.com/?4bx1xlx668r6kza
leepery,we will wait for OLED technology.i have a sony 46hx 700,the contrast is very good for a lcd display.

[madshi]

If you mean primaries, it might be a good idea to rename them
The settings read "the display itself is calibrated to the following primaries / gamut". I think that's as clear as it can get. I don't see a need to rename that.

and provide a hotkey to swap between them on the spot
No. We're talking about telling madVR how your display *itself* is calibrated. That's an information that will not change between movies, because movies have nothing to do with how your display is calibrated by itself. What you may want is a hotkey to swap/toggle the *source detection*, and in case you missed it, that hotkey was just introduced in v0.62. Maybe you should try v0.62 before making further suggestions.

We'd still need BT.601 transfer function coeffs instead of the default BT.709 for upscaled SD
Start testing v0.62. Come back after you tested it. Please no further comments until you tested v0.62.

[CruNcher]

madshi, are there any commercial decoders out there that support proper 16bit FourCC that will work with the next version of madVR?

i know @ least 1 you can get for free that supports v210 :) Cineforms Decoder :)

Edit: Ahh sorry 10 bit not 16 at least i didn't have any v216 material to test :P

[noee]

Interesting! Can you describe in which way it looks better?

Sharper image, more subtle color detail. I'm using a rip of Jeremiah Johnson for comparison, it's a nasty source (but a great movie!). There is a scene where Redford is helping put the door back on a cabin after an attack and you see it in the color of his trousers.

Also, in Star Wars (a new hope), in the hangar scene with the Falcon, the little lights in the background on the wall by the door are clearer, more vivid.

[SamuriHL]

i know @ least 1 you can get for free that supports v210 :) Cineforms Decoder :)

Hmm. Maybe I'll check it out at some point. Thanks.


Edit: Ahh sorry 10 bit not 16 at least i didn't have any v216 material to test :P


Oh sure. :D

[madshi]

madshi, i have this,in avi uncompressed ,I hope it's good.
Yes - thanks!

Sharper image, more subtle color detail. I'm using a rip of Jeremiah Johnson for comparison, it's a nasty source (but a great movie!). There is a scene where Redford is helping put the door back on a cabin after an attack and you see it in the color of his trousers.

Also, in Star Wars (a new hope), in the hangar scene with the Falcon, the little lights in the background on the wall by the door are clearer, more vivid.
Interesting, thanks for the description. I think it's probably caused by the change in chroma upsampling. Older versions upsampled chroma with the soft algorithm directly from source resolution to target resolution. madVR v0.62 now upsamples chroma always by 2x with the soft algorithm, then uses the Luma algorithm to scale the whole RGB (luma + chroma) to the target resolution. That might help color resolution for SD content a bit, while still keeping aliasing down.

[CruNcher]

so the next release gonna support the 4 letters ;) ?

[janos666]

First we would need material thats actually encoded like this. 99.9% of all content is 8 bit these days.

Wouldn't the 10/16 bit connection (between the decoder and renderer) be useful with 8-bit source materials too (like it is theoretically useful to output float32 from the DTS decoder, even though it's a 16-bit track)?
Aren't there any rounding(/dithering?) steps during the decoding?

[madshi]

so the next release gonna support the 4 letters ;) ?
Of course. I'll name v0.63 "LOVE", just for you. Or is that not the 4 letters you meant? :p

[CruNcher]

DXVA Surface speed test: :D

[madshi]

Wouldn't the 10/16 bit connection (between the decoder and renderer) be useful with 8-bit source materials too (like it is theoretically useful to output float32 from the DTS decoder, even though it's a 16-bit track)?
Aren't there any rounding(/dithering?) steps during the decoding?
Good question, but I think the video decoders work differently compared to lossy audio decoders. Lossy audio encoders convert to time domain which is a conversion which results in floating point data. That's why decoding lossy audio codecs results in floating point data. Video decoders work very differently, so I guess they don't produce floating point output by design. However, 10/16 bit connection can still make sense for professional use (studios, encoding houses etc). Furthermore, if you have some kind of processing before madVR (e.g. avisynth) it would definitely be beneficial to not have to downconvert the data to 8 bit in the middle of the processing chain.

Maybe someday someone will create a DirectShow splitter + decoder for www.RED.com content? That would be high bitdepth. They have a free SDK available, but I don't have the time to work on that, unfortunately.

[janos666]

Why can I select 10-bit as native display bit depth if it doesn't really output 10-bit?
Is it there for later versions with 10-bit output capability or did you think that it changes anything with 8-bit output if the display is theoretically capable of more? :)
Or should it work and the problem is on my side?

[e-t172]

Good question, but I think the video decoders work differently compared to lossy audio decoders. Lossy audio encoders convert to time domain which is a conversion which results in floating point data. That's why decoding lossy audio codecs results in floating point data. Video decoders work very differently, so I guess they don't produce floating point output by design.

Lossy audio decoders convert to time domain using the iDFT (inverse Discrete Fourier Transform), which is a floating point transform. AFAIK, lossy video decoders use the iDCT (inverse Discrete Cosine Transform) which is also a floating point transform. I don't see why one would benefit from floating point processing and not the other.

[nevcairiel]

Video decoders often use fixed-point optimized iDCT approximations to increase speed at a minimal quality loss.
I'm sure some video decoder pro can explain it properly, but video decoders just don't work like that. They output the same pixel format that was fed in. If it would be beneficial to increase bitdepth on output, i'm sure someone would've come up with the idea before..

[madshi]

Why can I select 10-bit as native display bit depth if it doesn't really output 10-bit?
Is it there for later versions with 10-bit output capability or did you think that it changes anything with 8-bit output if the display is theoretically capable of more? :)
It was meant for future versions, I should probably remove it now and only allow 6bit, 7bit and "8bit or higher". The net effect if you switch this option to 9bit now is that the dithering noise will be cut in half, which will re-introduce a tiny amount of banding, since output is still at max 8bit. So setting it to more than 8bit is currently not a good idea.

Video decoders often use fixed-point optimized iDCT approximations to increase speed at a minimal quality loss.
I'm sure some video decoder pro can explain it properly, but video decoders just don't work like that. They output the same pixel format that was fed in. If it would be beneficial to increase bitdepth on output, i'm sure someone would've come up with the idea before..
I've been told that the h264 spec is so strict that decoders are expected to output bit identical results. Not bit identical to the original source, of course, but bit identical compared to other decoders. I don't have the knowledge to confirm or deny this information, but if it's true then that pretty much says that floating point output would not be an improvement for h264 at least. I've also heard that MPEG2 is different and there decoders seem to have slightly different output results. So maybe for MPEG2 having floating point output would make sense. I've no clue, though.

[JarrettH]

So do you have to change the BT space depending on the video you playback now? I just use EVR-CP for DVDs, but everything else with madvr varies

[madshi]

What happened to making the SD or HD selection based on the pixel width of the video?
That's still the case. What do you mean?

[Gleb Egorych]

madshi, thanks for the nice update!

Made some tests of 0.62. Playback of 60fps files on 60Hz is very smooth with 8 pre-presented frames (no glitches). Very rare glitches with 4 pre-presented frames. Practically the same as 0.61 or maybe a little better.

I've noticed some improvement in playback of 25fps videos on my 60Hz display, I think it's better than 0.61. And D3D11 is now better and smoother than D3D9. I think it's close to EVR.

Some words about new dithering setting. My display has "virtual 10-bit" panel (8-bit + FRC) but in madVR my best setting is 7-bit. It is the best tradeoff between noise and banding (used colors.ytp for the tests).

[JarrettH]

Sorry I kind of clarified my own question and edited it. How do I know whether my monitor is using 601 or 709 though? When I calibrate my monitor, it's done for photo editing (2.2 at 6500K) on an NEC EA231WMi.

Edit: There's actually a drop down option for BT 709 I just realized.

Should I assume to use BT 601 until I create my own profile for BT 709?

[madshi]

Some words about new dithering setting. My display has "virtual 10-bit" panel (8-bit + FRC) but in madVR my best setting is 7-bit. It is the best tradeoff between noise and banding (used colors.ytp for the tests).
Interesting.

Sorry I kind of clarified my own question and edited it. How do I know whether my monitor wants 601 or 709 though? When I calibrate my monitor, it's done for photo editing (2.2 at 6500K) on an NEC EA231WMi.

There's actually a drop down option for BT 709 I just realized.

Should I assume to use BT 601 until I create my own profile for BT 709?
I don't really know for sure. 2.2 at 6500K is correct for both BT.601 and BT.709, I think? I'm not really the expert in this area, I'm always asking yesgrey for backup when such questions come up... :o

So do you have to change the BT space depending on the video you playback now? I just use EVR-CP for DVDs, but everything else with madvr varies
No, you shouldn't have to change anything depending on the video you playback. You should set up the display "properties" once and then forget about it. madVR should automatically perform all necessary conversions, depending on whether you play PAL, NTSC or HD content. madVR just wants to know what your display is calibrated to (or nearest to) so the conversions are done in the best possible way.

[Carpo]

how do you calibrate yCMS for use with madVR? is there a separate package i need to get and place in the madVR folder?

[bjd]

@madshi

Many thanks for this update. Even with the default settings (which I always stick to), the colors on my display seem far more natural on the content I have tested and I have also noticed the PQ seems slightly sharper as well on default settings - anyone else noticed that ?

[madshi]

how do you calibrate yCMS for use with madVR? is there a separate package i need to get and place in the madVR folder?
Just use the controls in the madVR settings dialog. It will offer to download the separate yCMS package for you. It should all go automatically (after you confirm that you're ok with that).

Many thanks for this update. Even with the default settings (which I always stick to), the colors on my display seem far more natural on the content I have tested and I have also noticed the PQ seems slightly sharper as well on default settings - anyone else noticed that ?
Wow, you're the second person who reports a noticeable quality improvement. Didn't really expect that. But hey - good news!

[Carpo]

Just use the controls in the madVR settings dialog. It will offer to download the separate yCMS package for you. It should all go automatically (after you confirm that you're ok with that).


I have selected it and clicked apply, madVR doesn't ask for anything, and it has net access, even restarted the player

[madshi]

I have selected it and clicked apply, madVR doesn't ask for anything, and it has net access, even restarted the player
When you activate the "calibrate this display by using yCMS" option, a new tab named "yCMS" should appear. In that tab you need to provide primary/gamut measurements for your display (and eventually grayscale measurements, too, but that's optional). If you don't provide gamut measurements, yCMS has no job to do, that's why madVR doesn't even try to download it in that case.

I understand that this behaviour might be confusing. I'll consider changing the settings dialog so that it forces you to enter gamut measurements when you activate the "calibrate this display by using yCMS" option.

[Carpo]

guess i best start reading on how to do that then :)

[6233638]

Hmmmm... I like short logs. But these logs are so short that there's simply not enough information in them. Did you cut them down? Playback has barely started in these logs.I did not. The problem is that playback wouldn't start and I would be stuck with a black screen.

It looks like either 0.62 and/or the new Nvidia drivers have fixed this now, as I don't seem to be having problems using the switcher.
That mostly applies to DOWNscaling, though. I'm not sure if linear light scaling brings much benefit for UPscaling, which is what most madVR users do.I don't have access to a machine with Photoshop right now (easiest way for me to test it) but I know that many of the high end hardware video scalers boast about the improvements that doing their scaling and gamut correction in linear light brings. Perhaps it matters more for downscaling, but I was under the impression it applied everywhere, especially if chroma may be getting upscaled and luma is not.

(4) 6233638: It was you who preferred Bicubic for chroma upscaling, correct? Please recheck your preferences with v0.62.It is, I'm looking forward to spending a fair bit of time testing this. :D

(5) Please note that madVR now accepts 4:2:2 connections. It is now *your* duty to make sure the decoder outputs the optimal format (which is usually 4:2:0).Is there a preferred format? I have stuck with YV12 up to this point. Should I just enable both NV12 and YV12 and let the decoder decide?



A couple of questions about the new options:
You now have the option to specify 10-bit for the display. Does this mean FSE will now output greater than 10-bit? (and could you please add it to the OSD if that is the case?)

From testing in Windowed mode, as bringing up the preferences kicks you out of FSE (a keyboard shortcut might be a useful addition) using 7-bit seems to work best on my "10-bit" LCD - though that may just be because it's only getting 8-bit sent to it, and 7-bit's dithering masks the edges slightly better with colors.ytp


I'm definitely excited about being able to leave my display calibrated to 2.20 for desktop work, and having madVR output 2.35 gamma (what film is intended to be played back at) without changing display presets.

Currently I have display and target output both set to 2.35. In theory, this should be no different from 2.20, is that correct?



A problem I'm having that happened occasionally in 0.61, and now more frequently in 0.62, is that if I leave FSE by any method other than hitting CTRL + Enter, I get massive amounts of dropped frames. Usually alt-tabbing to something else and back to MPC-HC fixes this. It's not a major issue, as I will watch in FSE, but it's a pain to have it happen when I just wanted to quickly change subtitle settings etc.

[SamuriHL]

@madshi - holy snikes man! I have to concur with the others who say that DVD PQ is VASTLY improved! I have my TV calibrated to BT.709. Whatever you did to the color space changed the clarity of the PQ immensely. It now beats PDVD10 which was my gold standard for DVD...until now. :) Fantastic!

[madshi]

I don't have access to a machine with Photoshop right now (easiest way for me to test it) but I know that many of the high end hardware video scalers boast about the improvements that doing their scaling and gamut correction in linear light brings.
Hardware video scalers? You mean like HQV Realta and Gennum? AFAIK they don't do linear light scaling!

Is there a preferred format? I have stuck with YV12 up to this point. Should I just enable both NV12 and YV12 and let the decoder decide?
There is no preferred 4:2:0 format from madVR's point of view. I don't know if decoders prefer a specific format.

You now have the option to specify 10-bit for the display. Does this mean FSE will now output greater than 10-bit? (and could you please add it to the OSD if that is the case?)
No, not yet. I will remove the 9bit and 10bit options in the next build, they make currently no sense.

From testing in Windowed mode, as bringing up the preferences kicks you out of FSE (a keyboard shortcut might be a useful addition) using 7-bit seems to work best on my "10-bit" LCD - though that may just be because it's only getting 8-bit sent to it, and 7-bit's dithering masks the edges slightly better with colors.ytp
FWIW, the "colors.ytp" is supposed to show slight edges between all those cubes. Please don't look for the cube edges. What you should look for is any kind of "movement" in the picture. If you get the impression that anything in the image is moving, then the dither strength is too low. The "colors.ytp" should only change colors, there should be no visible movement. Try disabling dithering completely as a test. Then you'll see what kind of movement I mean.

I'm definitely excited about being able to leave my display calibrated to 2.20 for desktop work, and having madVR output 2.35 gamma (what film is intended to be played back at) without changing display presets.

Currently I have display and target output both set to 2.35. In theory, this should be no different from 2.20, is that correct?
Having both at 2.35 should be no different than having both at 2.20, that is correct. I'm curious to hear whether letting madVR "modify" your display gamma works well or not. I hope it does.

@madshi - holy snikes man! I have to concur with the others who say that DVD PQ is VASTLY improved! I have my TV calibrated to BT.709. Whatever you did to the color space changed the clarity of the PQ immensely. It now beats PDVD10 which was my gold standard for DVD...until now. :) Fantastic!
http://madshi.net/icon_crazy.gif

[SamuriHL]

I have a specific test video section for testing DVD quality. I used it to hammer on ArcSoft until they fixed DVD quality for the AMD cards in TMT5. PDVD10 was literally the best I'd seen on it until now. madVR before wasn't BAD, but, it wasn't as good as PDVD which was odd since I use the PDVD video decoder to decode all my video. :) Anyway, this particular video will show any kind of colorspace issues and I really should have picked up on that before with madVR....it was too dark. The movie and scene I'm referring to? Empire Strikes Back, lightsaber battle with Vader. Look at his suit. That has such an awesome diversity of black levels that it shows pretty quickly whether there's an issue or not. madVR now actually slightly beats out PDVD for those scenes for me. So, again, well done. That's pretty amazing since you weren't intending to "fix" anything! :D

[Carpo]

Either its me seeing things, wanting to believe, tripping out, or migrain meds kicking in, but batman begins and the dark night look different on my TV with new madVR, colours look better

[SamuriHL]

The only real way to tell if it's "better" is to compare it with something. :) I don't necessarily rely on my eyes as the power of suggestion is pretty powerful sometimes. ;) Hence why I just compared my favorite scene with PDVD.

[Carpo]

I used older version of madvr, without using 3dlut, i will look again in the morning, maybe a fresh brain and fresh eyes might bring more comprehensive results ;)

[SamuriHL]

Indeed. :)

madshi, on that particular Empire Strikes Back video (it's an MKV ripped from the DVD using MakeMKV so no DVD nav issues or any of that). I'm using J. River's MC16 these days and when I hit stop MC16 crashes:

Faulting application name: Media Center 16.exe, version: 16.0.103.0, time stamp: 0x4de951e6
Faulting module name: madvr.ax_unloaded, version: 0.0.0.0, time stamp: 0x4debb286
Exception code: 0xc0000005
Fault offset: 0x4a40457a
Faulting process id: 0x690
Faulting application start time: 0x01cc23c87e4ac9aa
Faulting application path: C:\Program Files (x86)\J River\Media Center 16\Media Center 16.exe
Faulting module path: madvr.ax
Report Id: 5e27a91c-8fbe-11e0-9e0a-001fd080d928

Doesn't seem to happen on blu-ray rips. Is this an MC16 bug do you think?

[DigitalLF]

Quote:
Originally Posted by DigitalLF View Post
MadShi: i got a homemade 2:35:1 masking system and i use it on the lower part of my 16:9 screen and i would really like to see your seekbar to stay inside of the movie even when i resize 2:35:1 to 16:9 (ffdshow move blackbar to the lower part of the screen) would this be possible?? it would really mean alot to me
Properly supporting special projection setups is on my to do list (I have a CIH projection setup myself). I don't know if I will be able to comfortably support your special setup, though. Maybe yes, maybe no, can't say.

forget about that... i was a but quick when i wrote the question....


it cannot be a good solution to do it that way... first i have to do for this to work with my remuxes i have to use 2 functions in FFDSHOW first CROP the movie to 1920x800 from 1920x1080 and then move the blackbars by using RESIZE and i can't figure out a way for FFDSHOW to know when its playing a 16:9 or a 2.35:1 movie... so... i got a jvc x3/RS40 so i got a rs232 port that i control with my keyboard or my android phone to move the picture (and much more.. light, power, music) so i have given up on the FFDSHOW solution but i do have a question for you and yesgray ..

post processing with FFDSHOW that way couldn't have been good for PQ, right?

[6233638]

New major issue: I cannot seem to get 4:2:0 into madVR now. Upsampling is being applied before the video gets into it.

This is with either the latest ffdshow or LAV CUVID outputting YV12 or NV12.

Easiest test is to set all scaling to nearest neighbour. In all versions up to 0.62, this looked awful. In 0.62, it's smoothed over. (especially noticeable with low-res flash videos, such as the test I used here (http://forum.doom9.org/showpost.php?p=1398130&postcount=2543))

Hardware video scalers? You mean like HQV Realta and Gennum? AFAIK they don't do linear light scaling!Lumagen boxes do. (or at least did, when I was beta-testing the Radiance)

No, not yet. I will remove the 9bit and 10bit options in the next build, they make currently no sense.Ah, that explains why they looked so bad!

FWIW, the "colors.ytp" is supposed to show slight edges between all those cubes. Please don't look for the cube edges. What you should look for is any kind of "movement" in the picture. If you get the impression that anything in the image is moving, then the dither strength is too low. The "colors.ytp" should only change colors, there should be no visible movement. Try disabling dithering completely as a test. Then you'll see what kind of movement I mean.Thanks, that's what I noticed when going above 8-bit. 8-bit showed no movement, but 7-bit helped mask the edges a bit. (and 6-bit looked the same as 7-bit with more dithering)

[e-t172]

FWIW, the "colors.ytp" is supposed to show slight edges between all those cubes. Please don't look for the cube edges. What you should look for is any kind of "movement" in the picture. If you get the impression that anything in the image is moving, then the dither strength is too low. The "colors.ytp" should only change colors, there should be no visible movement. Try disabling dithering completely as a test. Then you'll see what kind of movement I mean.

My tests show that the smallramp.ytp test is the best to detect these "movements" (noise). They become obvious near the dark end of the ramp. It is also useful to detect banding, so it is easier to set the balance between dithering and potential banding.

It seems the old TN panel in my PC monitor isn't so bad after all, since noise is clearly visible as soon as I switch to 7-bit.

[Budtz]

Thx for the new version.

I had a few bugs disappear since i upgraded to 0.62. They were not in the changelog thou. Am I correct in assuming that not every optimization and bugfix to existing feateres is in the changelog but only actual changes like new feateres and options?

Also are there any optimizations I can make to the new display properties settings in madvr? I do not know the calibration or bitdepth of my tv thou I have looked throu any documentation I could find.

[pirlouy]

No problem with this new version for now. I can't say if something was improved. I'm just able to detect things like tearing, or major frame drops (and there are none).

But now, I can clearly say that I'm totally lost with all these options (no problem if it helps others). I'll stay with default settings.

[mrcorbo]

Either its me seeing things, wanting to believe, tripping out, or migrain meds kicking in, but batman begins and the dark night look different on my TV with new madVR, colours look better

I see it, too. Immediately noticed flesh tones looked more natural and then watched the scene where Bruce is climbing the mountain to meet with Raz Algul (sp?) and the League of Shadows and the landscape's muted colors still looked muted (as they should), but colors on certain objects, such as clothing and most notably the "blue flower" really pop.

[janos666]

No, not yet. I will remove the 9bit and 10bit options in the next build, they make currently no sense.

Why don't you correct the bug on the other side? :cool:

But seriously... Do you have any incompatibility problems or theoretical technical concerns (*) with the 10-bit output? Or why does it has so low priority in your list? (I would guess I won't see it in this year.)

* I have one. I think no VGA can output real 10-bit through HDMI but DisplayPort only, and the measured 10-bit precision with the new Redeons is the same thing what you can measure with single link DVI -> dithering (after the VGA LUT).
At least I never heard about anybody who use (or even successfully tested) 10-bit output with MPC-HC and a Geforce card through HDMI connection. But I am not sure because Fermi theoretically supports DeepColor on paper, so...

[Andy o]

How have you tested? My 5770 outputs 10-bit RGB via HDMI and the GTX460, 12-bit, according to my display (reported as 30 and 36-bit), but I have no way to tell if there's a practical advantage at all, or if madVR can take advantage of it. I'm thinking I'm gonna test madVR's 10-bit output, and if it gives me more banding than 8-bit (due to less dither, 1/4 if I understood what madshi said above and I'm not mistaken), then I guess it's not real 10-bit.

[cyberbeing]

I need some clarifications on a couple things since I'm confused how the new setting dialog interacts with shaders, 3dluts, and yCMS.

Properties
primaries/gamut - Since it's very rare for any display without a hardware lut to have a perfect gamut, what should this be set to? To maintain accuracy without a 3dlut should I pick the closest option or 'Something Else'? What does madVR do (not do?) when 'Something Else' is selected? Does this setting do anything when using a 3DLUT?

gamma/transfer - I calibrate my gamma to an ambient light scaled REC.709 curve with Argyll CMS, and as I've learned this doesn't match how yCMS or Janos666's MPC-HC-mod calculates it, so I doubt it matched madVR shaders either... To maintain accuracy without a 3dlut should I pick the closest option or 'Something Else'? What does madVR do (not do?) when 'Something Else' is selected? Does this setting do anything when using a 3DLUT?

Calibration & Color & Gamma
Color & Gamma appears to be some sort of Output Gamma setting? So if you are doing gamma correction in a 3dlut with something like grayscale measurements & gamma_curve, or don't want any gamma correction at all, madVR is forcing you to change it? I don't want anything to touch the gamma I may or may not have specified in a 3dlut, so this is a major problem for me.

Bug: The Color & Gamma section should not be used by default when using a 3dlut. Gamma corrections should be done with the 3dlut (if needed) when one is used. Currently madVR uses shaders on-top for the 3dlut. An 'Native' gamma option is needed to disable madVR's gamma modifications when using a 3dlut.

Bug: When 'using yCMS' is selected, clicking edit in the yCMS tab doesn't load the template from the Color & Gamma sections. Same issue in both sections with the grayscale edit button.
Related question: Does madVR only accept yCMS settings separated by commas or can spaces be used like a normal yCMS config file?

Bug: Somehow the Calibration tab appeared in Color & Gamut section. Previously there was only a yCMS tab.

Bug: madVR shouldn't be creating 3dluts with Output_Transfer_Function set (currently always set to 1.0 0.0 0.45454545454545454545454545454545 0.0) since you are using yCMS presets. Do you have a reason for doing this? Will madVR misbehave is fed a 3dlut using the yCMS defaults for yRGB (no Output_Transfer_Function specified)?

Bug: madVR sets both input and output levels to RGB_Video (16-235) instead of RGB_PC (0-255). This will cause full-range videos to get clipped. Since you are using shaders for TV->PC conversion, madVR would need two luts (Video->Video & PC->PC) to workaround this issue and support full-range videos.

Feature Request: Option to have madVR create a 3DLUT with an external yCMS config file and set the lut as the external 3DLUT after creation.

Hopefully you add an option to disable all these forced gamma corrections in madVR 0.63. Until that happens, I guess I'm stuck using madVR 0.61. You've made things overly complex for something which should be very simple. I would like to see input settings grouped with their corresponding output settings, with an option to disable all this forced behavior and use defaults with identical behavior (taking yRGB into account) to versions prior to 0.62. Otherwise, you need to write some detailed documentation on what all these new settings do, and how they are related.

[nevcairiel]

New major issue: I cannot seem to get 4:2:0 into madVR now. Upsampling is being applied before the video gets into it.

This is with either the latest ffdshow or LAV CUVID outputting YV12 or NV12.


For LAV CUVID its not technically possible to upsample chroma. It'll always deliver 4:2:0, it is not able to deliver anything else.

My guess is that what you're seeing is probably a side-effect of the scaling changes madshi did, resulting in smoother chroma even on nearest neighbour.

[6233638]

For LAV CUVID its not technically possible to upsample chroma. It'll always deliver 4:2:0, it is not able to deliver anything else.

My guess is that what you're seeing is probably a side-effect of the scaling changes madshi did, resulting in smoother chroma even on nearest neighbour.There is definitely some kind of filtering going on, as I have chroma and luma both set to nearest neighbour. The decoder may not be the issue then, if LAV CUVID can only output 4:2:0.

It's my understanding that the new feature scales chroma to the luma resolution using your selected chroma algorithm, and then both are scaled to your display resolution using the selected luma algorithm.

MadVR 0.12 (went back to it to get a direct comparison when testing, but anything below 0.62 is the same)
http://img842.imageshack.us/img842/5451/14948697.th.jpg (http://img842.imageshack.us/img842/5451/14948697.jpg)

MadVR 0.62:
http://img204.imageshack.us/img204/395/062xo.th.jpg (http://img204.imageshack.us/img204/395/062xo.jpg)

This is with MadVR set to Nearest Neighbour on both.

[Andy o]

madshi, I have 1080i59, 1080p23, and 1080p50 in that order, in the auto rate change options. When I play a 59/60p video, madVR switches to the 23p option. Is it supposed to work that way? I'd rather have it switch to 1080i59. I don't have 1080p59 in the options cause I'd rather have the 29.97 fps videos play at 1080i59, and if I have 1080p59 there, 1080i gets ignored in its favor.

No, that's not how it's supposed to be. What happens if you only put 1080i59 in the auto rate change option? Does madVR switch to 1080i59 then? I rather guess that for some reason switching to 1080i59 doesn't work. Not sure why. Maybe Windows itself doesn't like it. Are you sure that this mode actually exists in your GPU display mode list?

I tried again with 0.62 and it still happens. When I leave only 1080i59, then it simply doesn't switch to anything for 59/60p content (tried from 23p and 50p). Happens both with LAV splitter and the MPC internal splitter.

My card can do 59i, it does work OK for 29/30p or 59/60i content, just not for 59/60p. Also, 59i is my default setting so my PC is more often than not at that rate (named 29i or 30i in CCC). I tried quickly with the Interframe sample video here (http://www.spirton.com/interframe/), but it also was happening with an interpolation avisynth script when madVR was being fed 60p.