Linux Fernetmenta's vdpau options
#31
Both ends of the cable need to operate in the same mode. You can't output full range and do the conversion for limited. Hence the work around introduced with vdpau studio level conversion is simple wrong.

Quote:If I do not set ColorRange to "Limited", the picture gets crushed.
This is one thing that may happen. In limited range values of 0 and 255 used for sync, furthermore the footroom might be used to transmit pluge.

The real pain in the ass is HDMI and CEA. Specifications are kept like secrets. While we are flying blind, devices like bluray players communicate with the sinks (TV) and know a lot more about the other end. Enhanced EDID can be up to 32k while we only see 256Byte. There is a lot of useful information transmitted like video and audio latency devices can use for lip sync.

Currently I don't know whether there is a chance to read out this data. I don't even know if proprietary drivers like NVidia do.

Quote:For an inexperienced person using XBMC or Openelec, a way to toggle within XBMC may still be helpful.
I still don't understand why you want to toggle.
Reply
#32
(2012-10-16, 17:50)FernetMenta Wrote: Both ends of the cable need to operate in the same mode. You can't output full range and do the conversion for limited. Hence the work around introduced with vdpau studio level conversion is simple wrong.

Is it technically possible to do conversion for limited (XBMC/VDPAU) and output limited (Nvidia driver), keeping BTB and WTW? Or is this not feasible?
Reply
#33
(2012-10-16, 17:50)FernetMenta Wrote: I still don't understand why you want to toggle.

Sorry, let me rephrase that... I do not want to 'toggle' back and forth. What I mean is I would like an option in XBMC settings that replaces the broken Studio Conversion, and can easily set your xorg to ColorRange "Limited".

This may help a user who is in the same situation as I am, where my TV cannot do RGB Full, without them editing the xorg.conf file manually.
Reply
#34
Removed accidential double post...
Reply
#35
Quote:Is it technically possible to do conversion for limited (XBMC/VDPAU) and output limited (Nvidia driver), keeping BTB and WTW? Or is this not feasible?

Not feasible and not required. OpenGL rendering is RGB full range, that's a given. Hence you have to convert to full range. Until XBMC has rendered the image to the graphics driver, there is no WTW or BTB. AFAIK video material does not make use of superwhite or superblack. That are terms created by the consumer electronics industry.
The advantage of limited range is that headroom/footroom allows for adjustments. That can't be done by XBMC, it has to be done by the graphics driver. e.g send pluge pattern to tv and adjust colors.

Quote:What I mean is I would like an option in XBMC settings that replaces the broken Studio Conversion, and can easily set your xorg to ColorRange "Limited".
The downside is that the xserver has to be restarted. But the idea in general is not bad, the entire configuration has to be much more user friendly.
Reply
#36
(2012-10-16, 18:50)FernetMenta Wrote: The downside is that the xserver has to be restarted. But the idea in general is not bad, the entire configuration has to be much more user friendly.
The way I look at it, whether I edit xorg.conf manually, or with an option within XBMC, I need to reboot. A menu option would just make the process smoother.
Reply
#37
(2012-10-16, 18:50)FernetMenta Wrote: The advantage of limited range is that headroom/footroom allows for adjustments. That can't be done by XBMC, it has to be done by the graphics driver. e.g send pluge pattern to tv and adjust colors.
Does this mean that I can't see WTW and BTB colours on calibration video material through XBMC? At least currently I have that problem and it's hard to clibrate.
With VDPAU studio enabled I could see WTW/BTB but had to set TV Black level to LOW (limited). Doesn't make sense for me but it worked.
So I need to find some pattern images and calibrate on them, not video.
Reply
#38
Quote:Does this mean that I can't see WTW and BTB colours on calibration video material through XBMC? At least currently I have that problem and it's hard to clibrate

Correct. When converting to full range values got clamped to [0..255]

The question is why do you need calibration patterns coming through video or through the cable in general. In digital video processing the values of color and luminance won't change even when you send them multiple times around the world. A TV should be capable of generating its own test pattern.
Reply
#39
(2012-10-16, 21:28)FernetMenta Wrote: The question is why do you need calibration patterns coming through video or through the cable in general. In digital video processing the values of color and luminance won't change even when you send them multiple times around the world. A TV should be capable of generating its own test pattern.
My (LG) TVs don't allow chaning advanced settings when using internal movie/picture player. Internal calibration images are not enough. So I need to be on an input, to get the advanced picture setting menu:-). Anyway, this is not an XBMC issue :-)
FernetMenta, thanks for very valuable info!


Reply
#40
(2012-10-17, 08:16)nielsek Wrote:
(2012-10-16, 21:28)FernetMenta Wrote: The question is why do you need calibration patterns coming through video or through the cable in general. In digital video processing the values of color and luminance won't change even when you send them multiple times around the world. A TV should be capable of generating its own test pattern.
My (LG) TVs don't allow chaning advanced settings when using internal movie/picture player. Internal calibration images are not enough. So I need to be on an input, to get the advanced picture setting menu:-). Anyway, this is not an XBMC issue :-)
FernetMenta, thanks for very valuable info!

There should be some calibration patterns that do the work without BTB and WTW (if I remember correctly...). A lot of AVRs just cut everything outside 16-235 anyway, so this is actually a common scenario.

Reply
#41
So, VDPAU studio color conversion should be disabled. What about RGB vs YCbCr444? Does that have any bearing on the picture quality (of the video stream, not the GUI)? Am I correct in assuming that RGB would be better, since apparently it gets converted to RGB full whatever you do, so another conversion step by the video driver from RGB to YCbCr444 (or RGB limited for that matter) is not helpful?

Second question, is there any reason why everything HAS to be converted to RGB (full)? Wouldn't it be better if the video stream was just outputted natively to the screen and eliminate the conversion to RGB completely? Isn't that what dedicated BluRay players do, too?
Reply
#42
Bring your eyes close enough to your display and you may see RGB in action. So that's a given, we render to a RGB buffer provided by the graphics card which represents the monitor.
The ideal solution may be:
- get a monitor (TV) which supports full RGB
- switch off all image processing done by the TV between the input and the native panel
- calibrate the monitor -> get a color profile
- use this color profile in XBMC

here is some reading: http://openelec.tv/forum/67-display/6150...mitstart=0
Reply
#43
does it still doesn't recommend to use vdpau HQ upscaling due to performance issue ? If yes, where is the problem - into nvidia drivers or xbmc code ?
Nvidia Shield
kodi 18.1 RC1
Reply

Logout Mark Read Team Forum Stats Members Help
Fernetmenta's vdpau options2