GSoC project idea: Expand boblight support
#1
I'm honestly not really familiar with XBMC code, but I'll just bring this up, as I'd really love to have this feature and have done some research in that area currently. I'd be happy to help and provide more information if somebody wants to have a shot at this. If you tell me: Do it yourself! I could really use some technical info and some pointers on where to look and what to change... anyway. Here goes:

==== Expand boblight support ====
* ''Summary'': Ambilight via boblight works really well in XBMC when watching movies, "expanding" the screen and adding to the overall experience. But it works ONLY when watching videos. It would be nice to have that feature for picture slideshows or music vizualization too.

* ''How to achieve this'': As I currently understand the technical side the rendered video data is scaled to a smaller image and then grabbed by the boblight plugin. This only works in video mode, naturally, and runs on the CPU. It would be necessary to render all XBMC visuals NOT to the OpenGL screen/backbuffer, but to a FBO/framebuffer and then downsample that framebuffer to another one that already has the size needed for boblight. The boblight plugin could then instruct XBMC to grab the downsampled framebuffer data when it is needed.

* ''Benefits'': Boblight support would work in ALL screen modes, in XBMC menus etc. Also the amibilight colors would resemble the SCREEN content, not the video content as it currently is. Downsampling the image would possibly use GPU resources, freeing up the CPU for other tasks.

* ''What does it touch in XBMC'': That I'm not sure of. Instructing XBMC to render to an FBO should be simple, blitting/downsampling before swapping the buffers too, reading the downsampled buffer too. All-in-all I don't expect changes in too many places and few lines of code. It could be necessary to re-create the buffers whne switching resolutions...
Hardware-requirements might go up, because two new buffers are needed: One screen-sized color buffer and one smaller color buffer for downsampling (~8MB GPU memory needed for a Full-HD 32bit color buffer). The feature could be TOGGLEABLE though and is barely needed on mobile platforms, thus the impact should be really low. Frame times have been measured to go up in the 1-4 millisecond-area when tested on platforms like Core i3, i5 (Ubuntu and Windows) and on the Raspberry Pi. See here.

* ''Requirements'': I have prepared a sort of testbed on my blog here using CMake and C++. That should get you started.

I'm happy to answer questions. Drop me an email, my contact can be found here or in the blog.

Best regards and thanks for XBMC btw!

Bim
Reply
#2
Oh man I'd love to see this get fleshed out either way! One neat addition would be some way to select which screen modes the boblight would be active. E.g., if I dont want it in menus but everything else.
Reply
#3
Would also be nice with 3D support.
Reply
#4
(2013-04-22, 20:37)raptorjr Wrote: Would also be nice with 3D support.
for that 3D support has to be integrated/merged first
Reply
#5
(2013-04-22, 22:27)da-anda Wrote:
(2013-04-22, 20:37)raptorjr Wrote: Would also be nice with 3D support.
for that 3D support has to be integrated/merged first

Why? I thought it "only" needed that the boblight addon knows what kind of format the 3D movie has? SBS or whatever format used. And then not only show the colors on the edge of the movie, but compensate and use half of the picture for the whole top/bottom of the LEDs.

Anyway, i hope it works some day, whatever needs to be added first =)
Reply
#6
Well, in my completely impartial opinion, I think that this is a great idea.

You seem to have the rendering part well though out, so kudos on that.
I do have some suggestions:

- Add code so that a skinner can decide which color to make the lights.
- Add code to make the lights a certain color on XBMC events, like red on a certain kind of error, although I guess the skin could also do that for you.
- Investigate how to analyze the video image and make nice light output from that, I've found that it's quite hard to make something pleasant.

In other words, you have the technical parts well thought out, but now make a list of features this will bring, like "I will add technical feature X, which will give the user awesome feature Y".

Good luck on your endeavor.
Reply
#7
(2013-04-23, 20:04)raptorjr Wrote: Why? I thought it "only" needed that the boblight addon knows what kind of format the 3D movie has? SBS or whatever format used. And then not only show the colors on the edge of the movie, but compensate and use half of the picture for the whole top/bottom of the LEDs.
Well, only because the movie is 3D halfSBS, XBMC might render it in 2D, TAB or cyan/magenta or whatever (which is already possible in 3D branch of elupus). That's why I think 3D support has to be merged first in order to see how the render paths change.
Reply
#8
Would love to see this also.
I can manage with prismatik for now but proper integration to boblight would be great
Reply
#9
Wow. Nice to see this thread finally being replied to... Smile

Quote:One neat addition would be some way to select which screen modes the boblight would be active. E.g., if I dont want it in menus but everything else.
That should be an easy one, just add a couple of switches to the config...

Quote:- Add code so that a skinner can decide which color to make the lights.
- Add code to make the lights a certain color on XBMC events, like red on a certain kind of error, although I guess the skin could also do that for you.
- Investigate how to analyze the video image and make nice light output from that, I've found that it's quite hard to make something pleasant.
I'd leave that alone. Just show whatever is on the screen like it works now for movies. You probably need to tweak your color settings though Wink

Quote:Would also be nice with 3D support.
I can see 3D support being a problem. But it might be easy to solve, because XBMC needs to decode the two 2D frames anyway, then send them to the display device in some way (SBS or whatever). If we can grab one of the frames we should be fine. One could blend the two, but I doubt the difference will be noticeably...
But, well yeah, the render paths need to be clear I guess.
Reply
#10
Something I just noticed:

(2013-04-09, 11:16)bim_overbohm Wrote: * ''How to achieve this'': As I currently understand the technical side the rendered video data is scaled to a smaller image and then grabbed by the boblight plugin. This only works in video mode, naturally, and runs on the CPU.

XBMC already uses the gpu to scale the video frame down to a smaller size, there's no scaling on the cpu happening.
Reply
#11
(2013-05-06, 15:34)bobo1on1 Wrote: Something I just noticed:

(2013-04-09, 11:16)bim_overbohm Wrote: * ''How to achieve this'': As I currently understand the technical side the rendered video data is scaled to a smaller image and then grabbed by the boblight plugin. This only works in video mode, naturally, and runs on the CPU.

XBMC already uses the gpu to scale the video frame down to a smaller size, there's no scaling on the cpu happening.
Ok. I honestly didn't know. When a "fullscreen grab" is done things would probably be different though...

It's nice to see you post. I had already posted on the boblight plugin issue, but I guess you ignored me after a while, which I can somehow understand... Wink
I hope my experiment are at least worth showing that this is technically possible and manageable perfomance-wise...
Reply
#12
Did you submit this to melange? Because I can't see it in the list of proposals there?
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.

Image

"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#."
Reply
#13
Is this just theory or can we test it in real life? Would like to see it working on music vis and menu Wink
Reply
#14
(2013-05-07, 08:07)schumi2004 Wrote: Is this just theory or can we test it in real life? Would like to see it working on music vis and menu Wink

It is a proposal for a project to start working on as part of the GSoC 2013 during the summer.
It needs to be accepted first before any work will be done on it.

If I get topfs2's comment correctly the OP might have forgotten to submit it to Google in time.
Reply
#15
(2013-05-07, 07:37)topfs2 Wrote: Did you submit this to melange? Because I can't see it in the list of proposals there?

No. More like
Quote:"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#."
Wink, because
Quote:"Student
This is you! A student participant in GSoC is typically a college or university student; the only academic requirement is that the accepted applicants be enrolled in an accredited academic institution"
This is sadly not me. I'm not a student anymore, so I probably won't be able to apply... I'm just bringing this up here, because I think it it is a good feature and I can maybe provide C++/OpenGL advice specific to the problem and/or do beta-testing (as-in Mentor the project) if needed and somebody will pick up the project eventually.
I could maybe "just do it yourself"™, but I'm not familiar with the codebase, it would take me some time to understand it, and I'm not sure whether I won't break anything...
Reply

Logout Mark Read Team Forum Stats Members Help
GSoC project idea: Expand boblight support0