Posts: 47
Joined: Jan 2007
Reputation:
0
Hi bobo1on1,
Looks cool, is that single channel RGB, or are you copying the Ambilight features (multiple RGB channels)
BOB.SMITH
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
On that setup there are two lights, left and right, which can be controlled individually.
However they're both configured to respond to the entire screen area, because that's how I like it.
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
2009-01-14, 20:57
(This post was last modified: 2009-01-14, 21:12 by bobo1on1.)
Using a wrapper for glXSwapBuffers makes the output written to boblightd synchronized to the video output, I don't think it's more efficient, glReadPixels is kind of a cpu hog, on the other hand so is XGetImage, and XShmGetImage which I implemented in the next version of boblight-X11.
One of the advantages is, you can choose what you want to do with the lights depending on what you're doing, for example if you're surfing the net you probably don't want the lights to react to the color on the screen because it's kind of annoying. But when you start a media player, you want the lights to act as an ambilight. So what you need is a boblightd client like boblight-constant which just sets the lights to a certain color, and a boblightd client which starts grabbing the screen whenever a certain app starts, like the wrapper for glXSwapBuffers. Of course this will only work if boblight-constant has a lower priority (which is a higher number) that the glXSwapBuffers wrapper.
One of the things on my todo list is that a client should know if its output is actually used, so in case it's not it can turn off its expensive capture routines.
I have made it multithreaded for better efficiency on dualcore systems, the glXSwapBuffers tries to lock a mutex, if it can it calls glXSwapBuffers, unlocks the mutex, unlocks another mutex which signals another thread that it can read out the pixel data.
This seems to be more efficient, glxgears gets 600 fps with a single thread and 800 fps with multithreading, however without the glXSwapBuffers wrapper it gets more than 3000 fps.
I must admit that because of the high framerate, this really isn't a good benchmark.
If you're going to implement a plugin for boblightd, don't expect the protocol to stay the same, coming up with a good future-proof protocol is on my todo list, as well as putting functions to talk to boblightd in a library, at the moment they're in a header file, which is a big nono.
Posts: 4,549
Joined: Dec 2007
Reputation:
17
topfs2
Team-Kodi Developer
Posts: 4,549
May I ask if your bob, maker of boblight, by your response?
If so, do you know if there is some form of documentation about the packages that are sent? because this is still during the initial discussions on how to implement it we are thinking of making it a python plugin, and we would probably need to write a python module for it then. Although the actual RGB Grabbing will be done in cpp, mainly we are going this route as we are unsure if boblight may be enough (mainly because it might not work on osx? and on plattforms beyond the three os´s) so we would ideally like to keep this as module as possible.
They current idea is that we will interpolate and resize the output image, via hw / sw to say 16x16 (nearest neighbor) and get the color values from that. This because we ofc want it to be fast but just skipping pixels (like boblight-X11) may make the color values abit of. Im still just very new to ambilight features so if you have any thoughts on the matter it would mean alot for us.
Cheers,
Tobias
If you have problems please read
this before posting
Always read the
XBMC online-manual,
FAQ and
search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the
forum rules.
For troubleshooting and bug reporting please make sure you
read this first.
"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Posts: 34
Joined: Aug 2008
Reputation:
0
hi there, just some (not so technical) input that might (or might not) be useful for your plans on integrating ambilight functions into xbmc:
I recently got hands on a real Philips ambilight TV and checked its behaviour. There are some obvious significant differences between the Philips ambilight behaviour and the behaviour I tried to gain with my patch:
1. delay: I tried to gain a zero-delay, so if the screen goes black, without a noticeable delay, the LEDs turn off, too. On a real Philips ambilight, even if you set the ambilight mode to "dynamic" there's always a noticeable delay which can be recognized when the screen turns very fast from very dark to very bright. However, during "normal" movie scenes, you barely recognize the delay.
2. turning ambilight off: When the screen goes black, my xbmc-patch turns the ambilight completely off. Very cool when watching e.g. the "die hard 4" intro in a dark room. you see some people with bright backlight, then the screen goes black for a artist credit and you sit in a completely dark room. Then the next scene, ambilight is bright again and so on...
A real Philips ambilight never turns off. even when the screen is completely black, there is always at least a white dimmed backlight. Problem with my patch: sometimes in dark scenes, the ambilight turns red. This probably has something to do with LEDs not scaling their brightness in a linear manner. However, by making sure, all leds have a defined min-brightness you can avoid this behaviour, by the price of not having the LEDs turned off in dark scenes.
3. calculating average / skipping pixels/frames / downscaling / floating average
it seems to me, that Philips doesn't simply calculate the screens average color, but the seem to search for peeks or highlights, e.g. on a mainly grey scene, when there is say one big red dot, there would be two peeks (grey and red) in a corresponding histogram. philips seems to do create such a histogram to find peeks and somehow priorize colors (in the above case, the philips tv would have red ambilight). this would of course eat way more cpu time, but seems to be the better algorithm. at least in my patch, in normal movie (means lots of different colors during all scenes) the ambilights main color is white and mainly its brightness changes what still is a cool effect, but a little bit more color, like when watching the "philips endulge your senses"-video, would be nice, too.
Thats just my 5 cent
HTH
Cheers
dave-o