View Full Version : madVR - high quality video renderer (GPU assisted)
madshi
13th December 2012, 13:07
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.
Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).
Thanks, will double check here. Could you upload a short debug log, nevertheless, just in case I can't reproduce it here?
Madshi, levels are now incorrect using 85.3 with dxva scaling and mpc-hc internal decoder and splitter. Blacks are now grey. Other scaling methods provide proper levels. I'm using the old path exclusive without overlay on an Amd card.
Which exact OS, GPU and driver version? Can you please also upload a short debug log?
I have accidently realized that there's a huge performance issue since v0.85.2 (v0.85.1 is OK) when I using post resize pixel shader (sharpen complex 2) in mpc-hc on my laptop (720p content upscaled to 1680*xxx).
test (using nvidia inspector):
- v0.85.1: MCU usage: 19%, GPU usage: 53%
- v0.85.3: MCU usage: 30%, GPU usage: 78% (!!!!)
If I disable post resize shaders in mpc-hc, everything is the same between the 2 builds (or 0.85.3 is even slightly better).
v0.85.1 stored custom pixel shader results in 16bit integer video levels. That's the internal data format madVR uses for temp buffers in its render pipeline, so I didn't have to do any funny conversions. However, VMR9 and EVR always ran pixel shaders in PC levels. So v0.85.3 now converts the internal madVR data to PC levels before running the custom pixel shaders. And since I don't want to lose BTB and WTW, I can't use 16bit integer textures, either, so the pixel shader passes are stored to 32bit float textures. The levels conversions and the 32bit float textures are probably causing the higher load on your GPU. I guess I could add another "trade quality for performance" option to only use 16bit float textures instead of 32bit float. That might restore *some* of the lost performance, on the cost of ever so slightly less precision. But it will most probably not get back to v0.85.1 performance levels.
Then signal Full Quantization Range in AVI InfoFrame - HDMI Sink shall understand this and shall use 0 - 255 quantization range. Only RGB colorspace shall be used for Full Quantization Range. Or perhaps force HDMI to DVI mode then only 0 - 255 RGB is allowed.
Yes, that would be the ideal solution.
If we use digital sources (i mean MPEG-2, H.264) then choice is quite simple 704 and 720 pixels, 702 - 716 problem affect only analog capture sources and knowledge about capture device is required to understand real number of pixels in captured source. This purely source/display dependable relation - to be precise we need to know what timing is used by grabber and what timing is used by display. Without this everything will be educated guess.
FWIW, I've just accidently looked at my h264 header parser. It has a few custom aspect ratios. E.g. there is "16:11 720x576 16:9 frame with horizontal overscan". If I do the math, this specific aspect ratio ends up with 1047x576. Which happens to be the exact resolution 704 pixels would end up with. So I guess 704 pixels seems to be the "magic" number here for ITU scaling? If I follow the ARs defined in the h264 spec, I would end up with the following resolutions:
PAL 4:3 - 785x576
PAL 16:9 - 1047x576
NTSC 4:3 - 655x480
NTSC 16:9 - 873x480
I could offer this as an "ITU Aspect Ratio" option, in case madVR gets PAL/NTSC content with non-ITU 4:3 or 16:9 Aspect Ratios. Objections, anyone?
omarank
13th December 2012, 13:46
:thanks: for adding the double/ triple expanded source levels toggle. I have two questions regarding the way madVR handles video levels:
1. If I increase say Black Level of source from 0 to +1, madVR changes the video levels by 0.5 (I guess) for regular content. Now if I change the Black level to +1 in case of a 10 bit content, will madVR change the video levels by 0.5 only or by 2 (=0.5*1023/255)?
2. If I switch to double expanded source levels while playing a 10 bit content, what levels are considered then?
madshi
13th December 2012, 13:52
The black/white level controls always change exactly one step in 8bit. The visible change is the same for 8bit and 10bit sources, so for 10bit sources, increasing source black level from 0 to +1 results in a change of 4.
TheShadowRunner
13th December 2012, 13:54
I notice something strange with the screenshot feature.
Not using DXVA at all and playing a movie, when I take a screenshot it's much darker than what's on the screen,
My TV expects 16-235 so that's what I set in madVR. The movie is also encoded in limited range and the decoder outputting in YV12.
But it seems the screenshot feature expands to PC levels? (black crush)
I'm pretty sure old builds didn't have this issue..
I don't use color controls either on the player (ZP) or in madVR.
omarank
13th December 2012, 14:02
The black/white level controls always change exactly one step in 8bit. The visible change is the same for 8bit and 10bit sources, so for 10bit sources, increasing source black level from 0 to +1 results in a change of 4.
OK, thanks for the clarification.
madshi
13th December 2012, 14:03
I notice something strange with the screenshot feature.
Not using DXVA at all and playing a movie, when I take a screenshot it's much darker than what's on the screen,
My TV expects 16-235 so that's what I set in madVR. The movie is also encoded in limited range and the decoder outputting in YV12.
But it seems the screenshot feature expands to PC levels? (black crush)
I'm pretty sure old builds didn't have this issue..
I don't use color controls either on the player (ZP) or in madVR.
BMP, JPG, PNG etc are usually always 0-255, so that's what madVR produces for screenshots.
TheShadowRunner
13th December 2012, 14:09
BMP, JPG, PNG etc are usually always 0-255, so that's what madVR produces for screenshots.
Oh.. could we have a feature to grab exactly the source color range then?
When I use the ffdshow grab feature, or change madVR to VMR9 and use also ZP to make a screenshot, the resulting image is exactly what's on screen (PNG).
It's strange, I could have sworn madVR used to take exactly what's on screen in previous builds. ^^;
iSunrise
13th December 2012, 14:14
FWIW, I've just accidently looked at my h264 header parser. It has a few custom aspect ratios. E.g. there is "16:11 720x576 16:9 frame with horizontal overscan". If I do the math, this specific aspect ratio ends up with 1047x576. Which happens to be the exact resolution 704 pixels would end up with. So I guess 704 pixels seems to be the "magic" number here for ITU scaling? If I follow the ARs defined in the h264 spec, I would end up with the following resolutions:
PAL 4:3 - 785x576
PAL 16:9 - 1047x576
NTSC 4:3 - 655x480
NTSC 16:9 - 873x480
I could offer this as an "ITU Aspect Ratio" option, in case madVR gets PAL/NTSC content with non-ITU 4:3 or 16:9 Aspect Ratios. Objections, anyone?
IMHO, the whole ITU and non-ITU topic is already confusing the hell ouf of the majority of people which are using madVR. It will be used very rarely, if at all.
It certainly wouldn't hurt to offer it as an option, since I own about 800 DVDs (the majority is in NTSC format) I would like to give this a try myself. But I am not sure if I can even see a huge difference and if I want to go into the settings every time to change it.
hannes69
13th December 2012, 14:55
Originally Posted by hannes69
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.
Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).
Here the debug log: http://netload.in/dateixaiGwJat9z/madVR-log.rar.htm
Log created by using case (2). Hoping that helps ;)
leeperry
13th December 2012, 16:16
Why is he saying that? Ok, MPC-HC performs shaders in 8bit by default, I think, and cuts BTB and WTW. But that does not apply to madVR. The formula used by that script looks alright to me on a quick look. It converts TV to PC, though, so it's the opposite of what you want.
Yep, I would guess that the major issue with VMR9/EVR is indeed that BTB/WTW aren't preserved as you said :o
But I've got quite a lot of work ahead of me creating a dozen automatic gamut mapping profiles in PotP, so I don't plan on bothering with this script when a mere hotkey in mVR can do exactly what I want :p
Having users manually adjust frame scaling/cropping would be too troublesome
Well, I've got many different kinds of sources: VHS encodes, old and new PAL and NTSC DVD's, sloppy uncropped encodes....it's very easy when using a 4:3 display to stretch the picture horizontally in order to completely fill the screen, but it's a whole different story with 16/9 coz you never know where the 4:3 width actually stands and I'm afraid there will never be a "one size fits all" magic bullet to this issue :scared:
madshi didn't seem to like my idea of a 4:3 placeholder so I'll try to look into my options writing my own script, yay....no more whining, actions :D
I just want something like yellow rectangles in the 16/9 outer portions so I could clearly see the 4:3 limits =)
MPC provides hotkeys for pan & scan and I made my own pan & scan helper in PotP, so horizontal stretching really only takes me a few clicks: http://thumbnails102.imagebam.com/22556/391433225552817.jpg (http://www.imagebam.com/image/391433225552817)
pre and post are interchanged or they all run in pre?
they're all pre atm, a bugfix is in the works ;)
madshi
13th December 2012, 17:16
Oh.. could we have a feature to grab exactly the source color range then?
When I use the ffdshow grab feature, or change madVR to VMR9 and use also ZP to make a screenshot, the resulting image is exactly what's on screen (PNG).
It's strange, I could have sworn madVR used to take exactly what's on screen in previous builds. ^^;
madVR doesn't have screenshot functionality for that long, but for as long as it exists, it has always been PC levels. Before madVR had screenshot functionality, maybe you've pressed PrintScreen, and that produces the levels madVR is configured for. You can still do that, if you want.
I don't really see a good reason to produce BMP/PNG/JPG files with video levels. I don't have a spec at hand right now, but AFAIK BMP/PNG/JPG *always* have black at 0 by definition. I consider BMP/PNG/JPG files with video levels "out of spec".
Screenshots are often taken to upload them to the internet for comparison. And for that nothing else than PC levels makes sense. How could you compare screenshots with other people if some screenshots were TV levels and some PC levels? That simply makes no sense. Also, if you create video levels screenshots and send them to someone else who looks at them with his computer monitor, he'd see washed out black levels.
You're also the first person who's ever asked for screenshots in TV levels. I couldn't care less what ffdshow, VMR9 or ZP do. madVR does not aim to mimic what other software does. I'm doing things the way I consider "correct". The only way to convince me to offer an option to do video levels screenshot is to come up with a really convincing reason why that would be useful. It might also "help" if many more people requested that. But as long as you're the only one asking for this, and as long as I don't see much sense in your request, I'm going to stick with PC levels.
Originally Posted by hannes69
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.
Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).
Here the debug log: http://netload.in/dateixaiGwJat9z/madVR-log.rar.htm
Log created by using case (2). Hoping that helps ;)
Hmmmm... The log looks clean to me. Are you sure that you have all funny video processing options turned off in your GPU control panel (except deinterlacing related options)?
SyrupBuccaneer
13th December 2012, 17:22
Is that while the video is running? Or while the video is paused? While the video is running it is possible that the capture is a bit ahead of what is currently on screen. But while the video is paused you should really get the frame which is visible on screen. At least that's how it's supposed to be.
Same behaviour when paused. I tried disabling the madVR buffers [or at least change buffer to '1'] but that didn't change anything.
And it's the same behaviour whether I choose 'capture source' or 'capture real screen'
I don't know if it will tell you anything but I uploaded a log: http://www.mediafire.com/?6nsmums66f6jch7
-Open video
-Seek ahead
-Take capture
-Exit
chros
13th December 2012, 17:23
v0.85.1 stored custom pixel shader results in 16bit integer video levels. That's the internal data format madVR uses for temp buffers in its render pipeline, so I didn't have to do any funny conversions. However, VMR9 and EVR always ran pixel shaders in PC levels. So v0.85.3 now converts the internal madVR data to PC levels before running the custom pixel shaders. And since I don't want to lose BTB and WTW, I can't use 16bit integer textures, either, so the pixel shader passes are stored to 32bit float textures. The levels conversions and the 32bit float textures are probably causing the higher load on your GPU. I guess I could add another "trade quality for performance" option to only use 16bit float textures instead of 32bit float. That might restore *some* of the lost performance, on the cost of ever so slightly less precision. But it will most probably not get back to v0.85.1 performance levels.
Thanks for the explanation.
Can't you add back the way how it was working in 0.85.1 with a checkbox somewhere?
If it's too much trouble then I'm waiting for the next build and see how it performs with the reduced quality setting...
Thanks!
toniash
13th December 2012, 17:38
Thanks for the explanation.
Can't you add back the way how it was working in 0.85.1 with a checkbox somewhere?
If it's too much trouble then I'm waiting for the next build and see how it performs with the reduced quality setting...
Thanks!
Could you also test the overhead of only PS? (without upscaling or downscaling) Thanks!
hannes69
13th December 2012, 18:17
:rolleyes:Hmmmm... The log looks clean to me. Are you sure that you have all funny video processing options turned off in your GPU control panel (except deinterlacing related options)?
Yes, I am sure ;) Iīm using one of the latest MPC HC builds, madVR 0.85.3, LAV filters 0.54.1, AMD Catalyst 12.6 (the latest available for my Radeon HD4550, AMD stopped driver development for older GPUs like 4000 series) with Windows 7 64bit. In CCC everything concerning video is disabled. I also tried enabling them, nothing changed. So they stay disabled.
I use the AVS "color steps pattern" to determine the color shift. Blue stays the same, red gets a little less, green gets much more with using native DXVA decoding vs. software (or DXVA copy back). With native DXVA the top 4 green blocks get full saturated (so not distinguishable anymore), red gets slightly more saturated. I havenīt tried any other DXVA decoder, only the one from LAV.
Edit: Tried CoreAVC DXVA, same as LAV.
Tried NV12 and YV12 color space, both the same problem.
No further ideas...
Ahh almost forgot to mention: EVR doesnīt show the problem. Same configurations, just selected EVR custom instead of madVR.
What a pity, I have to blame madVR, really donīt like that, but one has to be honest...:rolleyes:
ryrynz
13th December 2012, 20:38
Is that while the video is running? Or while the video is paused? While the video is running it is possible that the capture is a bit ahead of what is currently on screen. But while the video is paused you should really get the frame which is visible on screen. At least that's how it's supposed to be.
That's like when I have exclusive mode enabled and I try taking a screenshot, I just disable exclusive mode with a keyboard shortcut and use Print Screen personally.
SyrupBuccaneer
13th December 2012, 21:23
That's like when I have exclusive mode enabled and I try taking a screenshot, I just disable exclusive mode with a keyboard shortcut and use Print Screen personally.
That's what I thought at first but it occurs in windowed mode as well. It's easier on Potplayer I guess because I can quickly switch between renderers using the context menu while it's playing, take a capture with EVR and then switch back to madVR.
TheShadowRunner
13th December 2012, 21:26
madVR doesn't have screenshot functionality for that long, but for as long as it exists, it has always been PC levels. Before madVR had screenshot functionality, maybe you've pressed PrintScreen, and that produces the levels madVR is configured for. You can still do that, if you want.
I don't really see a good reason to produce BMP/PNG/JPG files with video levels. I don't have a spec at hand right now, but AFAIK BMP/PNG/JPG *always* have black at 0 by definition. I consider BMP/PNG/JPG files with video levels "out of spec".
Screenshots are often taken to upload them to the internet for comparison. And for that nothing else than PC levels makes sense. How could you compare screenshots with other people if some screenshots were TV levels and some PC levels? That simply makes no sense. Also, if you create video levels screenshots and send them to someone else who looks at them with his computer monitor, he'd see washed out black levels.
You're also the first person who's ever asked for screenshots in TV levels. I couldn't care less what ffdshow, VMR9 or ZP do. madVR does not aim to mimic what other software does. I'm doing things the way I consider "correct". The only way to convince me to offer an option to do video levels screenshot is to come up with a really convincing reason why that would be useful. It might also "help" if many more people requested that. But as long as you're the only one asking for this, and as long as I don't see much sense in your request, I'm going to stick with PC levels.
Thanks for your extended answer.
I'm sorry this doesn't make sense to me at all.
If I'm taking a SCREEN SHOT, I expect the program to do just that, take a screen shot.
Not expand to PC levels, not do any tricks whatsoever, just capture exactly what's on screen.
Of course madVR doesn't aim to mimic other programs, but it's just what one expects!
Besides 99% of the contents is in limited range to begin with, so certainly people comparing screenshots would want to compare what the source is, without any color level modification?
I don't get it o_O
So please consider making the screenshot feature exactly that, a screenshot feature (!)
Or if you want the default behavior to do something else, please at least allow users who need and expect "exactly what's on screen" [a screen shot] to be able to do so, via an option somewhere?
Having to use PrntScr when a screenshot feature is implemented is.. nuts! XD
And maybe I'm the only asking that because other users haven't noticed yet? ^_^;;
See you,
TSR
SamKook
13th December 2012, 22:01
It's actually called a save image functionality if you're using MPCHC so you're not necessarily expecting it to take exactly what's on screen from the name but to save an image of the frame.
With that said, it would be nice to have both options. Not simply have the tv levels for the second(if they're applied), but also the resizing and all the applied filters so we could compare the effects of the different processing options more easily.
It could be useful for showing people how the quality of the picture can change with certain settings since most of them are clueless. That way they can be informed and choose which they prefer with less effort.
madshi
14th December 2012, 01:36
Same behaviour when paused. I tried disabling the madVR buffers [or at least change buffer to '1'] but that didn't change anything.
And it's the same behaviour whether I choose 'capture source' or 'capture real screen'
I don't know if it will tell you anything but I uploaded a log: http://www.mediafire.com/view/?t6bm44b4nj4a8xh
I'll have a look at the log tomorrow.
Can't you add back the way how it was working in 0.85.1 with a checkbox somewhere?
Not sure if I like the idea, I'll think about it.
Yes, I am sure ;) Iīm using one of the latest MPC HC builds, madVR 0.85.3, LAV filters 0.54.1, AMD Catalyst 12.6 (the latest available for my Radeon HD4550, AMD stopped driver development for older GPUs like 4000 series) with Windows 7 64bit. In CCC everything concerning video is disabled.
Ok. Still didn't get around to test this myself with an AMD card in win7 x64. Hopefully I'll be able to test that tomorrow. I just fear that this problem might only occur in your specific setup, for some funny reason, but we'll see...
I'm sorry this doesn't make sense to me at all.
If I'm taking a SCREEN SHOT, I expect the program to do just that, take a screen shot.
Not expand to PC levels, not do any tricks whatsoever, just capture exactly what's on screen.
If that's what you want then PrintScreen is exactly your ticket. What madVR offers is support for this official Microsoft interface:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd389570%28v=vs.85%29.aspx
This is how the media players create "screenshots" with madVR. The name "screenshot" is misleading, because really what the media players do is ask madVR for an RGB representation of the currently shown video frame *before* scaling. So this is far from what you would typically understand under the name "screenshot". Really, if you want a screenshots in the true sense of the word, PrintScreen is exactly what the doctor has ordered. What madVR offers is an RGB representation of the frame, properly encoded to the standards.
Basically madVR tries to produce the same screenshot for the same Blu-Ray on every PC, regardless of your madVR display device settings. This is intentional, and I believe it's a good and important feature, so screenshots made by different people are truely comparable.
Besides 99% of the contents is in limited range to begin with, so certainly people comparing screenshots would want to compare what the source is, without any color level modification?
The source is almost always YCbCr 4:2:0, and no media player I know of accepts that kind of "screenshot" from madVR. So madVR has no other choice than to convert the image from YCbCr 4:2:0 to RGB. And that conversion alone already involves quite a lot of processing which can't be avoided. Whether madVR converts YCbCr to RGB PC or TV levels doesn't change the number of processing steps, it just uses different matrixes, that's all.
And please have a look at the official PNG specification here:
http://www.w3.org/TR/PNG/#11IHDR
> The red, green, and blue samples determine the intensities
> of the red, green, and blue components of the pixel's colour;
> if they are all zero, the pixel is black, and if they all have
> their maximum values (2sampledepth-1), the pixel is white.
This clearly specifies that for 8bit PNG, black is at 0 and white is at 255. Which is exactly how madVR creates its "screenshots". The PNG spec does not have an option for video levels. PNG is always PC levels. So what madVR does is the only right thing to do, IMHO.
With that said, it would be nice to have both options. Not simply have the tv levels for the second(if they're applied), but also the resizing and all the applied filters so we could compare the effects of the different processing options more easily.
It could be useful for showing people how the quality of the picture can change with certain settings since most of them are clueless. That way they can be informed and choose which they prefer with less effort.
Options for providing screenshots before or after scaling/processing are planned for a (far away) future version. Currently I don't plan to offer video levels "screenshots" because I consider that to be "wrong".
TheShadowRunner
14th December 2012, 04:49
madshi, again thanks for this very detailed answer. I do understand the point you're making but am still baffled.
When I capture with VMR9, EVR or even Haali (all to PNG), the capture is in "limited range" and exactly what's on screen.
The microsoft document directly contradicts this? Or is it because those renderers work internally in limited range versus madVR working internally in full range?
When I capture with madVR, it's just completely black burnt and unusable.
I don't understand why madVR is the only renderer behaving this way.. do all the other renderers have it wrong?
6233638
14th December 2012, 05:05
madshi, again thanks for this very detailed answer. I do understand the point you're making but am still baffled.
When I capture with VMR9, EVR or even Haali (all to PNG), the capture is in "limited range" and exactly what's on screen.
The microsoft document directly contradicts this? Or is it because those renderers work internally in limited range versus madVR working internally in full range?
When I capture with madVR, it's just completely black burnt and unusable.
I don't understand why madVR is the only renderer behaving this way.. do all the other renderers have it wrong?I'm not sure I understand your setup.
In order to have screenshots appear "black burnt and unusable" that means your display is expecting video levels (16-235) and clipping everything below that.
For them to look that way, it means that your desktop is outputting 0-255 to your display, so it's not just screenshots, but rather everything except madVR that is having its levels clipped.
The problem here is not madVR, the problem is that you need to either fix your display's levels settings, or the video card's output levels.
I don't see any reason to take screenshots with video levels.
dansrfe
14th December 2012, 07:27
madshi,
I have an NTSC DVD that is telecined. madVR turns on deinterlacement and I change the source type to film but it seems like madVR is removing extra frames and the resultant motion isn't smooth.
Here's a 19 second sample cut from the film:
http://www.sendspace.com/file/i7eejt
Thanks!
TheShadowRunner
14th December 2012, 08:57
I'm not sure I understand your setup.
In order to have screenshots appear "black burnt and unusable" that means your display is expecting video levels (16-235) and
clipping everything below that.
That's right, my display is a Sony HDTV.
For them to look that way, it means that your desktop is outputting 0-255 to your display, so it's not just screenshots, but rather everything
except madVR that is having its levels clipped.
Yes, everything (desktop, etc..) except the video is clipped (I force madVR to use 16-235). The reason is: nvidia.
On XP, as soon as a Nvidia card is connected to HDTV via HDMI, the driver sends RGB Limited range 16-235 and there's absolutely no way around it (the Custom resolution trick or SetDefaultFullRGBRangeOnHDMI trick both don't work on XP [I'd love for someone to tell me how they did if they managed to make it work, on XP]).
It has never bothered me since I only watch movies on this htpc, so with the complete video chain set to 16-235, I still watch movies the way they were meant to be seen.
Besides, the least conversion happen in the video chain, the optimal PQ is, right?
According to Section 6.6 of the HDMI 1.3 Specification document:
<snip>While using RGB, Limited Range shall be used for all video formats defined in CEA-861-D,
with the exception of VGA (640x480) format, which requires Full Range.
Also it was my understanding that Full RGB is a legacy feature coming from DVI specification, therefore not applicable for a recent HDTV which expects RGB limited via HDMI in the first place.
I don't see any reason to take screenshots with video levels.
But, again, are all the other video renderers doing it wrong? When frame capturing from EVR, VMR9 or Haali, the images are all in video levels (as they appear on screen).
dansrfe
14th December 2012, 09:19
Outputting video levels on any display is kind of a thing of the past. Kind of in the same boat as having new movies come out on DVDs and interlaced footage.
My main question now is: Why is video levels still in the spec for Blu-ray material? What is the purpose of having limited range anyways?
diizzy
14th December 2012, 09:35
Is deinterlacing known to be broken on Intel HD Graphics (IB)?
Doesn't work at all even if I force deinterlacing.
//Danne
madshi
14th December 2012, 10:20
I have an NTSC DVD that is telecined. madVR turns on deinterlacement and I change the source type to film but it seems like madVR is removing extra frames and the resultant motion isn't smooth.
Here's a 19 second sample cut from the film:
http://www.sendspace.com/file/i7eejt
Will have a look at this later...
Yes, everything (desktop, etc..) except the video is clipped (I force madVR to use 16-235). The reason is: nvidia.
On XP, as soon as a Nvidia card is connected to HDTV via HDMI, the driver sends RGB Limited range 16-235 and there's absolutely no way around it (the Custom resolution trick or SetDefaultFullRGBRangeOnHDMI trick both don't work on XP [I'd love for someone to tell me how they did if they managed to make it work, on XP]).
It has never bothered me since I only watch movies on this htpc, so with the complete video chain set to 16-235, I still watch movies the way they were meant to be seen.
Besides, the least conversion happen in the video chain, the optimal PQ is, right?
Something is not right here. If your GPU outputs 16-235, then that practically means that your TV takes the Windows output (desktop, photos, games etc) and stretches it so that black (0) gets moved to 16. So if your GPU really outputs 16-235, your desktop should *not* be clipped. I think what is really happening is that your GPU outputs 0-255, which is actually a good thing. Then if your TV is set to 16-235, and madVR is set to 16-235, too, everything you're describing makes sense.
But, again, are all the other video renderers doing it wrong? When frame capturing from EVR, VMR9 or Haali, the images are all in video levels (as they appear on screen).
The bad thing about the other renderers is that you just can't rely on consistent behaviour. Let me explain how the other renderers work internally: They get NV12 YCbCr 4:2:0 and then use either DXVA or Direct3D to convert that to RGB. This YCbCr 4:2:0 -> RGB conversion is either done to RGB TV or PC levels, depending on the mood of the GPU driver. E.g. with NVidia there's a switch somewhere in the GPU control panel which defines whether this YCbCr -> RGB conversion produces TV or PC levels.
The MS video renderers don't really care much about PC vs. TV levels. They just rely on DXVA or Direct3D to convert to the "proper" levels. And then if you ask the MS renderers for a "screenshot" (again, the name is somewhat misleading), you'll get the direct output of the DXVA/Direct3D conversion. Which can be either TV or PC levels, depending on various different GPU settings. The end effect is that with the MS video renderers you can't really depend on which levels you'll get your "screenshot" in. On computer A it can be TV levels, on computer B it can be PC levels. All depending on whether the GPU outputs 0-255 or 16-235, and how the GPU control panel options are setup. IMHO this is all "wrong".
Let me tell you an experience I had several years ago, before I even thought about creating madVR:
There are sometimes different Blu-Ray encodings of the same movie in different countries. I like to compare them so I can get the best encoding of my favorite movies. When Pan's Labyrinth was released on Blu-Ray, there were about 5 different encodings available in different countries, some in VC-1, some in h264. So I looked at comparison screenshots on the internet and made a screenshot of the German Blu-Ray that I owned myself. And guess what happened? Due to my setup, my screenshot was not comparable to the other screenshots on the internet. So I actually thought for a while that the encoding on the German Blu-Ray had a different contrast or whatever. Only a while later I realized that my screenshot was at fault, due to incorrect levels.
I think the key point is that madVR creates screenshots that have black and white exactly where every other JPG and PNG file has black and white. So if you e.g. look at your vacation photos, and then look at a madVR screenshot, they both have black at the same level. If your vacation photos look alright on your display, then so will madVR screenshots. If neither of them looks alright on your display (due to how the GPU is setup etc) then it's not the fault of madVR, instead your display setup simply doesn't allow to watch any photos (and thus any madVR screenshots, either) with correct black levels.
Outputting video levels on any display is kind of a thing of the past. Kind of in the same boat as having new movies come out on DVDs and interlaced footage.
My main question now is: Why is video levels still in the spec for Blu-ray material? What is the purpose of having limited range anyways?
No. YCbCr video is in 99.99% limited range. And TVs usually do expect limited range RGB, too. Many newer TVs have a levels switch, though, to optionally also support full range RGB. Full range has historically been what PCs output. Limited range has historically been what consumer electronics (DVD players, Blu-Ray players, TV receivers) output.
Is deinterlacing known to be broken on Intel HD Graphics (IB)?
Doesn't work at all even if I force deinterlacing.
//Danne
It seems to be working with Sandy Bridge and Ivy Bridge. It has already been reported to not working on older Intel GPUs. I don't know why, and I can't really easily fix it, because I don't have access to such old hardware here, unfortunately.
6233638
14th December 2012, 11:11
That's right, my display is a Sony HDTV.How old is it? Anything recent enough to tell the driver to output 0-255 (default is 16-235 with HDMI unless the GPU is told otherwise) should be able to support it. It has to be outputting 0-255, if levels are being clipped.
If your TV is recent enough to have the XMB menus (https://www.google.com/search?q=sony+xmb&tbm=isch), the setting should be under:
Settings > Display > Video Input Settings > RGB Dynamic Range
"Auto" or "Full" should both work with 0-255.
Yes, everything (desktop, etc..) except the video is clipped (I force madVR to use 16-235). The reason is: nvidia.
On XP, as soon as a Nvidia card is connected to HDTV via HDMI, the driver sends RGB Limited range 16-235 and there's absolutely no way around it (the Custom resolution trick or SetDefaultFullRGBRangeOnHDMI trick both don't work on XP [I'd love for someone to tell me how they did if they managed to make it work, on XP]).Are you sure the card is outputting 16-235?
If the card was outputting 16-235, nothing should be clipped, as the card is compressing the levels, and a madVR screenshot would look correct.
If the card was outputting 16-235, and madVR is also outputting video levels, you will have the levels compressed twice so that video was being displayed at 30-218.
I think the key point is that madVR creates screenshots that have black and white exactly where every other JPG and PNG file has black and white. So if you e.g. look at your vacation photos, and then look at a madVR screenshot, they both have black at the same level. If your vacation photos look alright on your display, then so will madVR screenshots. If neither of them looks alright on your display (due to how the GPU is setup etc) then it's not the fault of madVR, instead your display setup simply doesn't allow to watch any photos (and thus any madVR screenshots, either) with correct black levels.I agree.
fallengt
14th December 2012, 14:23
How do I create a compatible 3Dlut file for Madvr?. I used DiscalGUI(argyllCMS) (http://dispcalgui.hoech.net/) to create icm profile and then create 3dlut profile(.3dl) from it but can't add it to madvr; "not valid 3dlut file" error.
vaporizer
14th December 2012, 18:23
crash report: radeon 7750 catalyst 12.10, mpc-hc 1.6.5.6261, lav filters 054.1 dxva-native, madvr 085.3, 2 monitors, 1x dvi / 1x hdmi
- 720p or smaller dxva: play video windowed, enter fse, return to window, move to other screen, crash (repeatable)
- 1080p dxva: play video on screen1 (windowed), move to screen2 (windowed), crash (repeatable)
always exception message 'access violation at address $4a4141a2 in module 'madvr.ax' read of address $0'
no problems if lav in copy-back mode, so maybe lav's fault. but no crash with evr cp.
if you need more infos... ask
Asmodian
14th December 2012, 21:43
How do I create a compatible 3Dlut file for Madvr?. I used DiscalGUI(argyllCMS) (http://dispcalgui.hoech.net/) to create icm profile and then create 3dlut profile(.3dl) from it but can't add it to madvr; "not valid 3dlut file" error.
You need to use yCMS (http://forum.doom9.org/showthread.php?t=154719) to create the 3Dlut file, or you can just measure the primaries and gamma curve of your calibrated display and write that into MadVR which creates the 3Dlut for you.
This is for converting the video's gamut to the display's gamut and displaying with the desired gamma, not doing what I would call a full calibration as is done with a "normal" CMS.
DragonQ
14th December 2012, 21:59
Found an example of incorrect ITU scaling on an HD upscale of SD material broadcast on E4 HD:
DVD = ITU (702x576= 16:9) (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/The%20IT%20Crowd%20-%20SD.png)
HD Upscaled = full-frame scaling (720x576 = 16:9) (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/The%20IT%20Crowd%20-%20HD.png)
HD Upscaled adjusted for ITU (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/The%20IT%20Crowd%20-%20HD%20Adjusted.png)
The HD upscale has more of the frame visible but I'm not sure which one of these is correct in terms of scaling. The black bars on either side of the HD upscale suggest that the DVD might be correct - if true, it's a shame that a public service broadcaster can't even get this right.
fallengt
14th December 2012, 23:48
This is for converting the video's gamut to the display's gamut and displaying with the desired gamma, not doing what I would call a full calibration as is done with a "normal" CMS.
nvm. I should read intruction first
glc650
15th December 2012, 01:17
Hello,
Been following the RGB level discussions of the last few days in this thread and I'm not sure how I should have this configured for my setup.
My TV does not seem to have any settings for this but from what I can gather online it supports 0-255.
So assuming this is correct, how should I setup CCC (Radeon 6570), madVR, and LAV video?
I use my HTPC for viewing photos and media playback (BR rips, AVCHD camcorder and GoPro footage).
Thanks,
->g.
dansrfe
15th December 2012, 01:41
So assuming this is correct, how should I setup CCC (Radeon 6570), madVR, and LAV video?
LAV Video: Untouched
madVR: 0-255
CCC: 0-255
TV: 0-255
TheShadowRunner
15th December 2012, 01:58
Something is not right here. If your GPU outputs 16-235, then that practically means that your TV takes the Windows output (desktop, photos, games etc) and stretches it so that black (0) gets moved to 16. So if your GPU really outputs 16-235, your desktop should *not* be clipped. I think what is really happening is that your GPU outputs 0-255, which is actually a good thing. Then if your TV is set to 16-235, and madVR is set to 16-235, too, everything you're describing makes sense.
I'm not certain what's going on tbh. I really do believe the nvidia driver is delivering RGB limited 16-235 to the TV, but that something strange is going on with the clipping (or not) of the desktop.
(I think so especially because in the nvidia panel, for "Digital Color format", changing between RGB <> YCbCR444 makes 0 difference when it comes to color levels)
(Desktop)
If I open paint shop pro and test colors 000000 to 161616, it's perfectly black. I do start to see (extremely faint) grayish around 171717.
(video)
If I play videos at 0-255, I suffer majorly of burnt blacks.
If I force madVR to 16-235, everything is fine, including the calibration files (1-Black Clipping.mkv, 2-APL Clipping.mkv & 3-White Clipping.mkv).
The bad thing about the other renderers is that you just can't rely on consistent behaviour. Let me explain how the other renderers work internally: They get NV12 YCbCr 4:2:0 and then use either DXVA or Direct3D to convert that to RGB. This YCbCr 4:2:0 -> RGB conversion is either done to RGB TV or PC levels, depending on the mood of the GPU driver. E.g. with NVidia there's a switch somewhere in the GPU control panel which defines whether this YCbCr -> RGB conversion produces TV or PC levels.Ah, I understand. I never touched this setting ("With the video player settings" is selected in nVidia panel) and it gives me 16-235 by default, with by exemple, WMP.
The MS video renderers don't really care much about PC vs. TV levels. They just rely on DXVA or Direct3D to convert to the "proper" levels. And then if you ask the MS renderers for a "screenshot" (again, the name is somewhat misleading), you'll get the direct output of the DXVA/Direct3D conversion. Which can be either TV or PC levels, depending on various different GPU settings. The end effect is that with the MS video renderers you can't really depend on which levels you'll get your "screenshot" in. On computer A it can be TV levels, on computer B it can be PC levels. All depending on whether the GPU outputs 0-255 or 16-235, and how the GPU control panel options are setup. IMHO this is all "wrong".
Thanks for clearing that up, I now get it. ^^;
And guess what happened? Due to my setup, my screenshot was not comparable to the other screenshots on the internet. So I actually thought for a while that the encoding on the German Blu-Ray had a different contrast or whatever. Only a while later I realized that my screenshot was at fault, due to incorrect levels.
You convinced me alright that different color levels for screen grabs depending on players/renderers/setups will trigger errors such as these and is less than ideal indeed.. ^^;
So if you e.g. look at your vacation photos, and then look at a madVR screenshot, they both have black at the same level. If your vacation photos look alright on your display, then so will madVR screenshots. If neither of them looks alright on your display (due to how the GPU is setup etc) then it's not the fault of madVR, instead your display setup simply doesn't allow to watch any photos (and thus any madVR screenshots, either) with correct black levels.
..and that's what I experience alright.
But regardless of the issue i'm experiencing, I still disagree on the fact that the best solution to "unify" screenshot color levels is to use PC levels.
After all the sources aren't the same. It makes sense for vacation photos or anything coming out of the PC world to be in PC levels.
But again, in the video world as we both know, 99% is in 16-235 color range by definition so taking "screenshot" using this color range makes more sense to me, if only to allow comparision with "screenshot" from other renderers which seem to be outputting 16-235 by default. XD
How old is it? Anything recent enough to tell the driver to output 0-255 (default is 16-235 with HDMI unless the GPU is told otherwise) should be able to support it. It has to be outputting 0-255, if levels are being clipped.
It's a Sony 40Z5500 from around 2 years ago, it was the top of the line model back then and does have the XMB menu.
Settings > Display > Video Input Settings > RGB Dynamic Range
I have no such setting :/
I only have "Settings" > "Picture" and "Settings" > "Video" (in which i can only alter/force the color format NTSC/PAL, etc..)
I do see a huge difference when I force the PS3 to output RGB full versus RGB limited, if it's any indicator..
Are you sure the card is outputting 16-235?
If the card was outputting 16-235, nothing should be clipped, as the card is compressing the levels, and a madVR screenshot would look correct.
If the card was outputting 16-235, and madVR is also outputting video levels, you will have the levels compressed twice so that video was being displayed at 30-218.Hmm I'm not sure about that, it seems like the nvidia driver has distinct color range behaviors for the desktop and video independently.(?)
I still do think the driver outputs 16-235 and my TV expects 16-235. Everything on the desktop that is really between 0-16 is brought back to black, so of course I suffer black crush for the desktop/pictures etc..
Is this reasoning flawed?
6233638
15th December 2012, 03:42
I still do think the driver outputs 16-235 and my TV expects 16-235. Everything on the desktop that is really between 0-16 is brought back to black, so of course I suffer black crush for the desktop/pictures etc..
Is this reasoning flawed?If the card was outputting 16-235, then nothing would be getting clipped on your display, because the card compresses anything rendered in 0-255, down to 16-235 specifically to avoid clipping.
If the card is outputting 0-255, and the display is set up only to accept 16-235, then anything outside the 16-235 range will be clipped.
It should like you have inadvertently managed to force 0-255 output when your display doesn't support that, and you should be sending it 16-235.
Even if you don't have a levels option, some displays will clip anything outside 16-235 by default, but it's not a hard clip, and you are able to use the brightness & contrast controls to have them display 0-255. (other displays that have a hard clip to 16-235, will never show anything outside the 16-235 range) Have you tried that?
There may also be a "super white" or some other option to switch your display's levels though.
EDIT: I've just read through your TV's manual and there doesn't appear to be an option for this. Strange, I thought all the XMB-equipped models had it.
The first thing I would try is switching to the "graphics" scene mode.
If that doesn't work, try adjusting brightness/contrast to see if you can make levels outside 16-235 visible.
If that doesn't work, you need to get your GPU outputting 16-235, and not 0-255.
glc650
15th December 2012, 04:45
LAV Video: Untouched
madVR: 0-255
CCC: 0-255
TV: 0-255And if I find out my TV doesn't support 0-255?
Is there some sort of test pattern/pic I can use to verify?
BetA13
15th December 2012, 05:02
this is an (black white) 0 - 255 PIC..on my CRT i see all color differnces..on my HD TC however i do not..on my hdtv i use 10 - 255 and its perfect now thanks to madshis custom color range option..
http://i155.photobucket.com/albums/s297/mikeyurkus/0-255BWDVD.png
16 - 255 gave me overgreyed blacks and artefacts in grey, black portions of teh screen..
Mangix
15th December 2012, 05:37
I found an annoying issue with madVR. On several .vob/.mkv files which are 30i, using LAV Video to decode it(software) results in deinterlacing being activated. The same is not true of madVR's built-in decoder. it says deintertlacing off (framerate).
manma
15th December 2012, 06:28
I FINALLY figured out why I'm getting dropped frames in madvr. Its leafs. Scenes with lots of green leafs, trees, and that sorta thing make my GPU usage rocket up to 100% and madvr starts dropping frames like crazy. Is there anything that could be done to make madvr handle leafs better? If it matters, I'm using Jinc4, and my GPU Is a GTX460.
ryrynz
15th December 2012, 07:31
Its leafs
It's leaves :)
I believe Jinc 3 AR is slightly less demanding than Jinc 4 AR so you could try that. If you still have frame drops and you want to keep using Jinc then I'd recommend overclocking your GPU or selecting a less demanding Chroma algorithm otherwise choose Lanczos 3 AR instead.
corporalgator
15th December 2012, 08:26
Sounds good to me. You do lose the values < 16 and > 235 this way, but these values are not supposed to be seen on screen, anyway, so it's not a big loss. You could also set your plasma to standard HDMI range and madVR to 16-235. That should be roughly identical in image quality for madVR playback, while preserving < 16 and > 235 data. But if you do that, your desktop and photos etc will have wrong black/white levels.
Thanks, I changed based on your suggestion and now am able to get btb and wtw. I calibrated black so 16 isn't visible and left most of the wtw, since those signals apparently exist on a lot of blu-rays like in chrome reflections.
Another question if you don't mind. My Plasma can do 60 hz and 48. It's a panasonic st30. When I send it 24p, I can switch to 48hz, but it has horrible flicker, so that's a no go.
So, I'm left with 60hz. My question is, I can have madvr switch the refresh rate to 24p, which means the tv does 3:2 pull down. The tv says the option is off, but since there's video playing on the screen, it must be doing 3:2. My other option is to not do refresh rate switching, leaving the video card at 60hz. Does that mean madvr is doing the 3:2 pulldown or is it my vid card? Which is preferable, letting the tv handle it, or sending it already switched?
manma
15th December 2012, 08:44
It's leaves :)
I believe Jinc 3 AR is slightly less demanding than Jinc 4 AR so you could try that. If you still have frame drops and you want to keep using Jinc then I'd recommend overclocking your GPU or selecting a less demanding Chroma algorithm otherwise choose Lanczos 3 AR instead.
Its funny, I actually wrote leaves, and then replaced each one with leafs before I hit submit for some reason. Weird how spell check likes both spellings.
alizard
15th December 2012, 10:04
Madshi, I'm using a AMD 4870 with 12.6 drivers on Windows 8 x64.
Here is the log file: http://www.filedropper.com/madvr-log
truexfan81
15th December 2012, 11:32
I'm just curious if anyone else has experienced this bug while using cuvid and madvr on win7
http://support.microsoft.com/kb/983615
thanks
ThurstonX
15th December 2012, 15:53
Its funny, I actually wrote leaves, and then replaced each one with leafs before I hit submit for some reason. Weird how spell check likes both spellings.
Well, to "leaf" is a verb, as in, While I sat in the dentist's office, I leafed through a magazine." So "leafs" is a valid spelling. It's all about context ;)
Yeah, horribly OT, but it seems a slow Sat. But definitely try something less demanding than Jinc4 :D
khanmein
15th December 2012, 16:50
guys my bro lappy unable to use GT630M on mpc-hc? how to solve it? using 306.97
goldie
15th December 2012, 16:52
madshi, many thanks for your great work, Jinc/AR/DXVA2native/ColorControls! (maybe I'm lag :p) Good job, keep going.
wanezhiling
15th December 2012, 16:53
guys my bro lappy unable to use GT630M on mpc-hc? how to solve it? using 306.97
http://forum.doom9.org/showpost.php?p=1603351&postcount=15891
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.