2011-08-16, 12:20
only certain TV's support this colorspace not every one does.
2011-08-17, 02:58
X3lectric Wrote:only certain TV's support this colorspace not every one does.
Which colorspace are you referring to? Full range RGB, or YCC444? Any TV with HDMI should, as per the HD standard, accept YCC444.
2011-08-17, 03:00
YCC444
I say this cause I have seen tvs now that when you drop to terminal go green screen instead of black and many ppl who I know have said similar not all though. mines one a samsung series 5 and it goes green. So for better or worst I rahter it black since Im disabled and cant be pissing around te place and have to use terminal on xbmc box ...
I say this cause I have seen tvs now that when you drop to terminal go green screen instead of black and many ppl who I know have said similar not all though. mines one a samsung series 5 and it goes green. So for better or worst I rahter it black since Im disabled and cant be pissing around te place and have to use terminal on xbmc box ...
2011-08-17, 07:05
I've actually noticed this behavior with colorspace set either way. For some reason I've never really been able to drop to terminal from xbmc, regardless of which version I'm using. Oddly enough though, booting off of other live distros works fine.
2011-08-17, 07:13
in xbmclive vanilla with git compile twist ontop thers no issue, thing is you get a greeen screen, soon as I removed the HD colrspace it wh=ent back to black
could be a driver issue I tried setting just the gpu same thing happens. idk I cant tell any difference except I dont have green.
A long while ago w e had to add a grub twek to get terminal but since grubpc as evolved and matured I dont see the need. it was something like vga=492 or whatever, idk...
anyways now sbm refuses to browse unless I enter hardcoded paths gui is slugish and NFS doesnt work for me... ANd Im sleepless again and trying to rescue about 2 TB of data.
could be a driver issue I tried setting just the gpu same thing happens. idk I cant tell any difference except I dont have green.
A long while ago w e had to add a grub twek to get terminal but since grubpc as evolved and matured I dont see the need. it was something like vga=492 or whatever, idk...
anyways now sbm refuses to browse unless I enter hardcoded paths gui is slugish and NFS doesnt work for me... ANd Im sleepless again and trying to rescue about 2 TB of data.
2011-08-17, 10:47
the green stuff happens here too! with output set to YCC, terminals are green.
2011-08-17, 15:23
PatrickVogeli Wrote:the green stuff happens here too! with output set to YCC, terminals are green.
And I bet your not the only one cause I have some friends with same stuff, so much for standards, they say one thing, but if they implement it or not is another.
2011-08-17, 18:30
Not tried dropping into a terminal as I do all that via putty remotely and it always looks the same.
When the system is in the last stages of shutting down the screen(attached directly to xbmc)does go green briefly which it doesnt do without the colorspace=y.... option set.
also a samsung tv although I doubt that is the cause.
When the system is in the last stages of shutting down the screen(attached directly to xbmc)does go green briefly which it doesnt do without the colorspace=y.... option set.
also a samsung tv although I doubt that is the cause.
2011-08-18, 02:44
Never noticed the green console messages at boot or shutdown. I get black screen on boot until the logo comes up, and I get white on black console messages during shutdown or reboot.
I am running OPENelec nightly ION 64bit version though, not stock XBMC.
I am running OPENelec nightly ION 64bit version though, not stock XBMC.
2011-08-18, 03:44
perhaps its the tea does make the brew? perhaps non..
2011-08-18, 23:21
For cross reference see my take on this - that YCbCr mode is not necessarily a better thing for xbmc, and is not what people imagine it to be.
http://forum.xbmc.org/showpost.php?p=858...stcount=20
http://forum.xbmc.org/showpost.php?p=858...stcount=20
2011-08-18, 23:33
TheSwissKnife Wrote:For cross reference see my take on this - that YCbCr mode is not necessarily a better thing for xbmc, and is not what people imagine it to be.
http://forum.xbmc.org/showpost.php?p=858...stcount=20
Yea so what does your opinion say about this thread, your quote
TheSwissKnife Wrote:Seems to me this is another example of how incomplete/incorrect info gets proliferated.I would say its on a case by case,
Openelec uses it, what you think about that? So some ppl are right and others wrong on same subject..? or is this all colorspace BS?
jebus time for spiderpig....
2011-08-18, 23:55
Please, don't think in terms of black and white. TheSwissKnife clearly says "not necessarily ...".
YCbCr makes sense as a default for OpenElec, because it's a safe choice. As I've stated many times already, some HDTV's simply accept only YCbCr or maybe RGB limited. If you feed those kind of TV's full RGB, blacks and whites will get clipped. That's very noticeable. The fact that some extra conversion has to happen could be considered a small price to pay for making OpenElec working properly by default on all HDTV's without having to tweak the colour space in xorg.conf.
However, when you KNOW you have a TV that supports unadulterated full RGB as input, using it makes sense quality wise, because otherwise the colours will be converted from YCbCr (source) to RGB (as rendered by XBMC) to YCrCr (conversion by video card driver) and then back to RGB again (as displayed by the screen).
The shorter path is conversion from YCbCr (source) to RGB (rendered by XBMC) only once. The rest of the video path will be completely RGB.
YCbCr makes sense as a default for OpenElec, because it's a safe choice. As I've stated many times already, some HDTV's simply accept only YCbCr or maybe RGB limited. If you feed those kind of TV's full RGB, blacks and whites will get clipped. That's very noticeable. The fact that some extra conversion has to happen could be considered a small price to pay for making OpenElec working properly by default on all HDTV's without having to tweak the colour space in xorg.conf.
However, when you KNOW you have a TV that supports unadulterated full RGB as input, using it makes sense quality wise, because otherwise the colours will be converted from YCbCr (source) to RGB (as rendered by XBMC) to YCrCr (conversion by video card driver) and then back to RGB again (as displayed by the screen).
The shorter path is conversion from YCbCr (source) to RGB (rendered by XBMC) only once. The rest of the video path will be completely RGB.
2011-08-19, 01:23
I am not sure that YCbCr is the safest choice in any environment, and openelec is no reference for correctness. However, I am sure YCbCr will certainly be the choice that should give the correct nominal range (L=16-235) output levels for a display properly calibrated - thus GUI, pictures and video will look roughly right out-of-the-box. I am not sure about display devices not supporting RGB (I need to check HDMI spec for mandatory modes), but I can believe they might only consider RGB as full range or only as limited. But in this case there is the "limited" versus "full range" option - so then RGB could still be a possible option.
What I am saying really is that since YCbCr output mode has already been converted to RGB full range anyway inside XBMC so any gain related to accuracy (ie going from YUV source data to YCbCr output) is misfounded (ignoring VDPAU + Studio colour mode). For me, I can't accept that any attempt to go YCbCr or RGB limited output, loses the whites above level 235 and possibly colour differences outside the 240 range too. The only nvidia/linux mode that can keep this data intact RGB full range, AFAIK. In this case the downsides/weaknesses of XBMC in transforming GUI/image/video to suit this mode have to be considered too.
Currently there is no great solution, just compromises. I just wanted to chime in to help with fact gathering rather than inaccuracy proliferation...feel free to disprove or enhance my rhetoric.
What I am saying really is that since YCbCr output mode has already been converted to RGB full range anyway inside XBMC so any gain related to accuracy (ie going from YUV source data to YCbCr output) is misfounded (ignoring VDPAU + Studio colour mode). For me, I can't accept that any attempt to go YCbCr or RGB limited output, loses the whites above level 235 and possibly colour differences outside the 240 range too. The only nvidia/linux mode that can keep this data intact RGB full range, AFAIK. In this case the downsides/weaknesses of XBMC in transforming GUI/image/video to suit this mode have to be considered too.
Currently there is no great solution, just compromises. I just wanted to chime in to help with fact gathering rather than inaccuracy proliferation...feel free to disprove or enhance my rhetoric.
