[X3lectric]

Yea good luck with that.

[tocinillo]

With FernetMenta build (https://github.com/FernetMenta/xbmc/) pixmap branch! everything works and XBMC no crashes...try it!

Download file .tar.gz (from PIXMAP BRANCH) and install it: http://forum.xbmc.org/showpost.php?p=818...stcount=18

[TheSwissKnife]

strange thing, crashes are gone, hard to analyze what did i change... one thing comes to my mind, i changed colorspace from RGB Full to YCbCr444, can it be it? is it somehow related?

AFAIK you can't really be setting YCbCr444 mode because xbmc does not support it, due mainly I think to OpenGL only supporting RGB. Not sure which nvidia drivers you have but that mode was valid only since some version of 260.xx AFAIK.

[X3lectric]

AFAIK you can't really be setting YCbCr444 mode because xbmc does not support it, due mainly I think to OpenGL only supporting RGB. Not sure which nvidia drivers you have but that mode was valid only since some version of 260.xx AFAIK.

and on that note

http://forum.xbmc.org/showthread.php?tid...colorspace

openelec uses it as well. support is strictly to TV and gpu, tthough I cant imagine every old tv and gpu supports it but its clearly supported in most modern equipment.

[TheSwissKnife]

and on that note

http://forum.xbmc.org/showthread.php?tid...colorspace

openelec uses it as well.

Seems to me this is another example of how incomplete/incorrect info gets proliferated. Someone who knows xbmc can correct me if I am wrong but I believe xbmc is always RGB output only so the YUV stream already gets converted to RGB anyway. Also I believe the YCbCr444 nvidia mode only supports limited range if I remember rightly (see below). It would be great if there were a way round that to retain YUV throughout and it would reduce the load on the system too.

As for full range versus limited...from my tests a long while ago "Limited" clips everything outside limited range so you lose information from the stream, most importantly whiter-than-whites (and they do exist). Using "FULL" range ensures all data is kept as-is out of xbmc but in order to make video come out correctly adjusted at the black end (eg black = luminance level 16) alas needs xbmc to apply the YUV-to-RGB conversion with that in-mind which it does not do AFAIK except "probably" for the VDPAU case with studio color conversion option enabled - which I think assumes HD material so is incorrect for SD too anyway. In addition the GUI and the picture viewer will be output with black level at 0, so FULL range mode will retain that too and your display will not see the shadows unless you recalibrate to this incorrect black level.

The best solution assuming we stay with xbmc/opengl RGB output would be to have selectable YUV-RGB matrices that correctly transform based on what output type is preferred "PC" or "TV" for example. "PC" would transform things so that black is 0, "TV" would transform everything so that black is 16. This would need a matrix for each of SD and HD too. When I get a chance I may create such a patch.

[wsnipex]

The best solution assuming we stay with xbmc/opengl RGB output would be to have selectable YUV-RGB matrices that correctly transform based on what output type is preferred "PC" or "TV" for example. "PC" would transform things so that black is 0, "TV" would transform everything so that black is 16. This would need a matrix for each of SD and HD too. When I get a chance I may create such a patch.

Isn't that what the display driver should do, if I set it to output YCbCr444?
I understand its less then optimal to convert YUV -> RGB -> YCbCr and afaik RGB to YCbCr is lossy too (since YCbCr is a lot bigger color space) right?

[TheSwissKnife]

Isn't that what the display driver should do, if I set it to output YCbCr444?
I understand its less then optimal to convert YUV -> RGB -> YCbCr and afaik RGB to YCbCr is lossy too (since YCbCr is a lot bigger color space) right?

Yes, display driver should offer proper conversion, but it does not as far as I know - it scales 0-255<->16-235 (talking only about the luminance levels) - nvidia and others have this plain wrong. Moving back and forward between YUV/YCbCr and RGB causes quantisation errors and different devices use very slightly different conversion parameters so you can end up out by one quite easily. As you say also the colour spaces are very different sizes too so the quantisation into RGB tends to reduce the possible colour range immediately. In addition most displays I believe convert to YUV/YCbCr to implement the colour control, then have to convert finally to RGB to deliver to the final display stage - good devices will do these conversions at higher than 8-bit depth (so quantisation is "hidden") but it is not clearly documented exactly what they do.

[tocinillo]

The crash problem when auto refresh rate its enabled appears with latest git version (compiled today)....any ideas to fix it?

My S.O is Ubuntu 10.04 LTS and my GPU is GT430....until now I'm using latest FernetMenta pixmap branch, but its very outdated (June).

Regards!

[FernetMenta]

Once it turns out to be stable in my private branch I will factor out this part and submit to mainline for review. The only absolutely safe way to prevent from those crashes is to clear down vdpau resources during refresh rate change.

BTW: my outdated pixmap branch has not implemented this method and does also crash every now and then.

[tocinillo]

And this failure (crash xbmc) is a problem that affects all NVIDIA GPU or only GT4XX series? I say this because I do not see many post talking about this problem, Is it only affects us a few?

Once it turns out to be stable in my private branch I will factor out this part and submit to mainline for review. The only absolutely safe way to prevent from those crashes is to clear down vdpau resources during refresh rate change.

With your outdated pixmap branch I don't have any crashes at the moment....

PS: Very very thanks for your awesome work Fernet, really!

[wsnipex]

This does not seem to be vdpau only. The same thing happens with vaapi. Whenever a crash occurs, it seems to leave the gfx or framebuffer dirty. As a result the screen shows garbage.
This is just my uneducated guess, please correct me, if I'm wrong.

[tocinillo]

Any fix released for this bug? Is very annoying

Thanks!