[DerekCuster]

Hi,

Does anyone know if frodo will include support for playing back movies without interference/manipulation?

Currently, it seems xbmc strips every file from its native colour space to RGB and then expands and clips it on the way over to 0-255, then sends it to the gfx card to be converted back, only for the tv to convert it again.

Does anyone know if frodo will support standard he video rec709 ycbcr 4:4:4 16-235 colour space natively, without converting it o RGB and expanding it?

It seems awful wasteful and silly seems as xbmc runs on many devices now and not just pcs?

[Ned Scott]

patches welcome

[DerekCuster]

I have nicotine and pregnancy patches here if they are any good?

I'll take that a as no...
Thanks for letting me kne though.

[jmarshall]

XBMC correctly uses the colorspace as appropriate for the file to convert to RGB (fullrange) so as to write the image into the framebuffer, yes.

What your graphics card decides to do is up to your graphics drivers.

If you wish to convert to non-fullrange RGB to make up for some silliness at the driver level, then this is doable by altering the contrast and brightness (aka blacklevel). A search of the forums will reveal the magic numbers, though I'm sure you can probably compute them yourself easily enough.

[sialivi]

Would love to see this as well, would go very well together with the post-frodo PR for disabling upscaling.

[jpsdr]

If you wish to convert to non-fullrange RGB to make up for some silliness at the driver level, then this is doable by altering the contrast and brightness (aka blacklevel). A search of the forums will reveal the magic numbers, though I'm sure you can probably compute them yourself easily enough.

I've tried. Unfortunately, it's working only on video, not subtitles.
If you have colors defined in subtitles, which should match colors on the video, if you alter contrast and/or brightness, color in subtitles will not match anymore the colors in video, because apparently brightness/contrast has no effect on subtitles colors.
So, what seems a good idea, indeed is not.

[DerekCuster]

Also, adjusting the brightness and contrast is knocking off my gamma and color gamut slightly according to the readings on my i1D Pro so while that does "kind of" fix "part" of the issue, it's a long way off an actual fix.

It would be better for to just not convert a video to full RGB, particularly when the source isn't full RGB and the destination isn't expecting (or capable on some cases) of displaying full RGB. Xbmc is a video player (no pc specific) and should therefore use video levels, surly that's what all these video devices expect? I would say many users with a HTPC connected to a TV via HDMI are defaulting to ycbcr 4:4:4 (16-235) as that's what the gfx cards default to when connected to a tv. How many users go in and then set up a tv for full RGB, set up the gfx card for full RGB and then calibrate the devic based on full RGB? I'd say not many.

It seems like a completely unneeded procedure, and I'm sure that all these devices xbmc now run on, not all are running 0-255 full RGB. I'd say a good few are video levels 16-235.

Sounds like its not coming anytime soon anyway, no big I suppose, just a shame is all.

[jmarshall]

The math is exactly the same. i.e. the conversion to the so-called "video range" RGB (which should not exist as all it does is throw away dynamic range) from a YUV based color space simply has different constant and scaling coefficients than the conversion from a YUV based color space to full-range RGB. By applying contrast you alter the scaling. By applying brightness/black level you alter the constant coefficient. Once done with the correct coefficients the computation is mathematically identical.

We output fullrange RGB for the obvious reason: The UI is running at fullrange RGB thus everything else should be or it will look plain wrong.

Cheers,
Jonathan

[DerekCuster]

Or... the entire thing can/should be rendered in 16-235 to coincide with the "video" media it plays, the "video" devices it's played on and tvs (or video display unit) it's connected to? ... Just saying...

The world of video runs in 16-235, DVD, bluray, all digital video, HDMI/HDTV REC709, we calibrate to this standard, AVS / DIsney WOW / Spears + Munsil / HTPCs all calibrate to 16-235 standard, just seems strange that xbmc is the only player that doesn't conform to standards... It's like the IE Browser of the media player world...

[topfs2]

Why would you want to run a worse standard Full range is better, the non full range just throws away perfectly good bits.
It makes perfect sense that xbmc uses what the gui do for the video.

AFAIK The reason they have used the non-full range is because you can do some fixed precision, integer math trickery with YUV->RGB(16-235) which is far easier on the hardware. I.e. its a leftover from when hardware was slow, it wasn't because it was better they used it because it was _needed_.

And regarding xbmc being IE of the media player world, then please just go out and find chrome and stop complaining here. And most players does this afaik, WMC, Media Portal etc.

[jmarshall]

The world of video runs in the YUV colour space. For historical reasons this is limited to some subset of the range (16-240 or 16-235 depending on exactly is being dealt with).

RGB has always been full range. Don't confuse the two.

Cheers,
Jonathan

[topfs2]

The world of video runs in the YUV colour space. For historical reasons this is limited to some subset of the range (16-240 or 16-235 depending on exactly is being dealt with).

RGB has always been full range. Don't confuse the two.

Cheers,
Jonathan

hmm, perhaps I have missunderstood then?

I have a distinct memory of seeing some specialized matrix math (which I made a shader use for atv2 which was tons faster) but it only produced output in the non-full range. Or perhaps it was NTSC color range. Oh well I think I'm confused

[jpsdr]

You seem a little confused.
The standard are the following :
RGB is full range (0 - 255).
YUV, or, being precise, YCbCr is Y (16 - 235) Cb/Cr (16-240) centered on 128 for no color.
So, when converting, you should have :
RGB (0,0,0) <-> YCbCr (16,128,128)
RGB (255,255,255) <-> YCbCr (235,128,128)
Purely speaking, NTSC is a color mode format which concern only analog CVBS signals. When dealing with numeric data, PAL/SECAM/NTSC doesn't exist anymore, you're dealing with things like RGB, YUV, YCbCr and color matrix conversion.

A good start is here, after you can follow other links inside.

[DerekCuster]

There seems to a a lot of inconsistencies with what the devs are saying lately, like the doozie in the alt f4 thread

[Martijn]

There seems to a a lot of inconsistencies with what the devs are saying lately, like the doozie in the alt f4 thread

If you know better you tell us then.
You comparing things that have nothing to do with each other or are way outdated.

And in what universe is two "a lot"?