Quote:
Originally Posted by madshi
No, that's actually not true.
NTSC, Blu-Ray and PAL all have different primary color coordinates. The differences are *NOT* dealt with by just using the correct YCbCr -> RGB matrix. E.g. if you take the color "red: 200; blue: 20; green: 20", this color is supposed to result in a different wavelength being produced by your display for NTSC content than for PAL or Blu-Ray.
Practically that means, if you display an NTSC SD DVD you have to calibrate your display to BT.601 primaries. If you display a Blu-Ray, you have to calibrate your display to BT.709 primaries. If you display a PAL DVD, you have to calibrate your display to PAL primaries. If you don't do that, you'll get incorrect colors. All of this applies even if you convert YCbCr -> RGB with the correct matrices!
The solution to this dilemma is to perform gamut correction. Basically if you have RGB data coming from an NTSC DVD, madVR converts this RGB in such a way that it no longer needs NTSC primaries, but instead it's converted to HD/BT.709 primaries. As a result you can display this NTSC on your BT.709 display now with correct colors. Which is *not* possible without gamut correction - unless you calibrate your display to BT.601 instead of BT.709.
|
I don't really know about this stuff, but are you saying that, since no renderer does gamut correction besides madVR, all of them will only display 1 type of content (NTSC, PAL, etc.) properly, assuming the display is locked to one of them? That rises the question: how does madVR know which correction it has to apply? You tell it your monitor properties, but how does it decide between the source options?
Quote:
Originally Posted by madshi
The real fault here is in ffdshow/fraps. They can not assume that no further conversion will be done because it's the duty of the video renderer to care about display levels. ffdshow/fraps don't even know on which display the output will be shown!!!! If you have a dual monitor setup and one monitor needs PC levels while the other monitors needs video levels, how would ffdshow/fraps know what is needed?? They are not in a position to make such decisions. Only the video renderer is. Configure ffdshow to leave levels alone and the double stretching will go away.
|
ffdshow does "know" on which display the output will be shown, you can change it in the settings. Default is PC range. Fraps is hardcoded, as all material recorded by it is PC range and virtually 100% of it will be displayed in PC monitors.
The renderer is not in position either. It has no way of knowing the original source levels, as far as I can see madVR just assumes TV levels for everything. Fraps and PC-range encoded H.264 sources will always be wrong as long as this behaviour doesn't change. ffdshow adapts to this because it has all the info, the renderer cannot, unless you offer an option not to process RGB input.
So what do we do, let the renderer assume source properties it doesn't have, or let the decoder assume monitor properties it doesn't have? The trend when YCbCr conversion is done in the renderer is to assume source properties, and the trend when the YCbCr conversion is done in the decoder (RGB output) is to assume monitor properties and not touching it in the renderer. You can go against the trend, but that won't give you much success I'm afraid.
Quote:
Originally Posted by madshi
madVR doesn't redo everything. madVR only performs those conversions which are necessary to achieve correct results. If there's double processing the reason for that is simply that madVR wasn't informed properly that another filter already performed the same operation before.
|
And how does madVR know which corrections are necessary and which aren't, when it doesn't know the original properties of the video?
The corrections madVR does now with all known (by me) RGB sources are incorrect because of this. That's the point, no filter I know of tells the renderer any of this info. The same issue happens when resizing SD content to HD, the renderer doesn't know that the source is SD and converts it with HD settings, you know the result. The common trend among renderers is to convert assuming their input resolution is the source resolution, just like the common trend is to not touch RGB input because it's assumed to be properly processed. There's no paper or anything that tells us where this should be done, but making asumptions nobody else does is a very bad idea IMHO, specially when there's no absolute right or wrong decission.
Quote:
Originally Posted by madshi
You're actually using EVR behaviour to proof a point? Are you serious!?
|
Nope. Just telling that madVR won't work correctly with any known RGB32/24 content, while EVR, VMR, Haali, etc. will work without issues. EVR was just an example.
Do you know of any filters that, when outputting RGB32, work without issues in madVR? I don't. That's the main point, how to make RGB32 not suck in madVR!