News with the Tag: Developer

For those of you using unstable or nightly builds, you will soon notice a change in available add-ons at the xbmc.org repository. Dharma users shouldn’t fret as nothing changes for stable add-ons. With each new version of XBMC, there are sure to be changes that require add-on authors to make changes…

Rather than focusing on developer work within the team, we thought we’d switch this post up to focus on work by the community at large. But before we do, a quick announcement. For those of you who don’t already know, we’ve decided to name XBMC 12 (the one coming after Eden*) Frodo, after one of the…

I promised an update a few weeks ago and here it is. Better late than never! There’s lots to discuss about what’s going on with XBMC development work. So how about this.. I’ll provide an overview as to what’s in the works, then respond to any questions/comments in a follow-up post. This information…

Update: There was a typo in Sigma’s press release and our resulting post. Their XBMC port was done on the SMP 8656 which supports Open GL ES. GLES will also be supported on Sigma’s recently announced SMP 8910, so this may be a potential target for XBMC as well. For those asking “Will a potential…

Today Sigma Designs announced(pdf) that they are working to bring XBMC to their popular line of system-on-a-chip models (their new SMP8656 in particular). For those not familiar with Sigma, they are a major player in the set-top box market and their SOCs are the heart of many products from Popcorn…

As we discussed in a recent post, XBMC is finally moving to a current SCM. Many of us have been using git-svn for quite a while anyway, but the burden of doing a real migration has kept us from making the switch. Today the migration begins. We have picked GitHub as our host due to their great…

At this year’s DevCon we took a long hard look our development process; we decided that while it works, it is starting to show a few cracks and we know we can do better. We have a lot of issues with the current development model, mostly due to a lack of communication between developers prior to…

Thanks to the excellent mirrorbrain project, we will be upgrading the backend to our mirror system tomorrow to take advantage of some new features, some of them were even added at our request (thanks again Peter)! As a result, beta testers for the upcoming Dharma release may experience a brief…

This is the last weekly report and I would like to thank google and the beagleboard community for the fun summer! It have been a wonderful opportunity and I’ve learned heaps and gotten extremely interested in embedded development. Status Done further investigation regarding finding the performance…

Before we go into the actual status report I would like to be abit nostalgic, this is the last week of feature addition after all. Before GSoC XBMC didn’t even compile on angstrom and now I just finished watching a SD video which ran without the BeagleBoard breaking much of a sweat! I have had much…

Status Overlay is scaled and positioned according to how the skin wants it. Overlay playback is tearing free and rather fast. Runs bunny 480p almost perfect while before it was about 5fps. Finally got crosscompile working. Thanks again koen for all your help providing me with builds up to this point…

Status OMAP Overlay is hooked up to XBMC and works rather well (for a few seconds) Switched the yuv transformation from swscale to the NEON method created by mru. Have created a hack that should get rid of the memcpy, needs major redesign though to get it into trunk though but probably ok to use for…

Last night jmarshall created the Dharma branch, which will eventually become the stable Dharma release. That means that from this point on, only fixes and important updates will go into the release branch, while trunk remains open for business. So for all the skinners, translators, and add-on…

Status Understood how OMAP Overlay works and how it should be done, thanks to måns awesome application omapfbplay. Implemented a VideoRenderer in XBMC which transforms from yuv420p to yuv422p via swscale. I might use the neon optimized from Måns at a later stage but for now I isolate the unknowns to…

Status Finally gotten the dirty region based rendering solution to work on the Beagle Board. During the week I’ve tried rendering to a framebuffer and render this buffer to the backbuffer but it was incredibly slow but Måns Rullgård (mru) pointed me to track dirty regions from 2 frames back, i.e…

It’s been quite a while since we’ve posted an update, but rest assured we’ve been very busy behind the scenes. The new add-ons system is now nearly complete, the only missing piece is the add-ons themselves. So let’s fix that! Here’s a quick refresher course for those who may have missed it. We have…

Last week have been a busy week indeed and I have focused on getting the dirty region based rendering to work. I am glad I followed my mentor’s advice and did dirty region before moving to an event based rendering, especially considering that when dirty region rendering works we have gotten an event…

Status Finally XBMC runs on Angstrom, turns out it was optical code paths deadlocking while loading. Commited a –disable-optical-drive on the gsoc branch. XBMC Runs on C4 at about 10-15 fps (15fps in 640×480 and 10 in 720p) but koen have tried it on the new BeagleBoard xM which does an amazing 38fps…

After discussion with my mentor we decided to not use the EVAS model suggested in my last weekly report. While it might have worked it would have taken to much time to realize which is a bad idea due to the limited time of GSoC. Hence I have started altering the guilib to do the actual event based…

Since I’ve been without computer the last week the status update will be slim. Status Committed the initial patches to get XBMC on Ångström building Decided on an abstracted rendering model which works like EVAS. Basically guilib will add drawable elements to the render system. When an animation…