Hi everyone!

As you all may or may not know I’ve been tasked to clean up parts of the scraping process in my GSoC project. A first step to this is to gather some information so that we statistically can say what formats your media is formatted in: do you usually have dots instead of spaces, do most add year to the folder name of a movie, etc. Many of you might alter this to fit xbmc so we want to somehow catch those we do not handle so we can try and find some pattern in those formats as well!

To do this, we’ve created a script that you can find in the Program Addons folder of your XBMC install called “Statistics gathering for scraping GSoC 2012.” What the script will gather is the bare essential metadata if scanned into the library, title, year, runtime, tvshow, episode number and season number etc. The file path is also stored as it is what generates this data and of great importance to know, saying that I want to note that we will NOT store any username or password information in any part of these URLs, this script is not meant to track the users and it cannot track you! The data is uploaded to a server which we on the team can view and no data about your system except the metadata and file urls are uploaded, no binary data from the files of any kind!

Even with these assurances, we know that not everyone will be willing to send in that limited information, so we’ve made this addon “opt in.”  In order to participate in the study, you have to install the addon from the Program Addons folder in XBMC. I urge anyone, those displeased with how our scraper handles their media and those where it works perfectly, to install this addon if you want to help do your part to make XBMC even more awesome. The more information we have, the better our scrapers will be.

Once again, the addon is called “Statistics gathering for scraping GSoC 2012,” and it may be found in the Program Addons section.

Cheers, Tobias

Update: There’s a (known) bug in the current version of the addon which makes it fail on start. It will be fixed ASAP. We are sorry for the inconvenience.

Update 2: The bug has been fixed and the updated addon is now available from the official repository. Before you install it, make sure it’s version 0.0.4. If not you can either force refresh XBMC’s official repository (using the context menu) or wait a few hours until it happens automatically. Once again, we are sorry for the inconvenience.

Update 3: The server is brought down while I go through and backup the data. You all might be interested to know that you almost took down the server with all the data :) So thank you all so much, you have given me more than I ever hoped for! I will post updates ASAP!

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 help from the extremely talented beagleboard community and it would have never been possible without them, now its almost possible to have a fully capable SD box made from the BeagleBoard with XBMC.

While not all of the original ideas made it into XBMC we have still come a long way and XBMC have went from not running to becoming rather usable on the BeagleBoard, still room left for more improvement ofcourse but still great progress IMO. Since the YUV transform is done by NEON and the hardware overlay videos actually run good, before GSOC it couldn’t even present the lowest resolution video at anything beyond 10fps.

It has been made clear what is slowing down GUI rendering and much lies in the skinners hands, which is what the next weeks documentation will be about. I have commited a minimal but still useable skin which might just hit 100fps ;). If we add backgrounds and make it static but close to looking as ordinary skins that number goes down to about 20fps, with the addition of the dirty region rendering this number actually gets to about 30fps, which was my goal for 720p!

Status

• Finally got the overlay to be under the controls which needs it.
• Created a minimal skin which actually hit vsync when rendering.
• Refactored the rendering passes and dirty region tracker to support N-buffering. Also added the new cost reduction algorithm, the cost reduction algorithm is using static costs now but could probably calculate dynamic costs if it got timing data back regarding its choices. I guess linear regression would work if we don’t use to old data points?

Plan

• Polish and add more dialogs and such to the minimal skin to make it a viable skin for day to day usage.
• Document what a skinner can do to make a skin which runs fast on BeagleBoard

Risks

• Can’t think of anything …

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

Plan

• Still need to get overlay under some of the GUI controls. I have tried rendering SGX with alpha bits on but haven’t gotten it to work, possibly set the blending mode of the overlay improperly.
• Find a low resource skin and limit it down as a start of a beagle skin.
• Investigate what the performance hog is in videoplayback using oprofile, the memcpy should be gone but its still far behind omapfbplay.

Risks

• My temporary apartment seems to lie in a wireless deadzone so my internet is incredibly slow. I will still be able to work (thanks git!) but my time on irc will be less and i will probably group commits more.
• A skin may hide the videoplayback temporarily, need to find a way to temporarily hide the overlay and possibly discard doing yuv transforms during this time. Not sure if its possible without reconfiguration (on hide and on visible) of the overlay.

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 beagleboard and possibly tegra to gain some speed while decoding video.

Plan

• Get to the bottom of the deadlock which makes playback stop after a few seconds
• Position the overlay properly according to skinning specifications (rotation will not be possible but nearly no skin uses that on video control so no real biggie).
• Get stuff rendering ontop of the overlay is still needed, so plan is to read through the documentation about the blending modes and how to setup so SGX shines through as supposed to.

Risks

• Time…. next week will be my final moving week and I need to clear out the entire apartment. Hence I suspect the following week will be hard to get much work done in. Weeks after this I’ll be setup and free in a new apartment  so I’ll take care of the time lost then.

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. what is undefined for 2 frames. This works since normally a graphics just flip the pointers between front and back buffers and as such if we know what we have rendered on both we can know what we need to render to have a perfectly defined backbuffer. While confluence uses lots of fullscreen animations its now getting to the point were its possible to create a snappy low resource skin, and when the old PM3 skin gets updated with the addon changes it might just be the perfect candidate.
• While many controls are working and marks dirty regions properly there is still a couple of vital ones left, most notably the lists.
• Tracked down why XBMC in Angstrom used up the entire CPU time thanks to some the wonderful program oprofile and help from Måns. It seems like SDL Audio (which we use for GUI Sounds) constantly poked the audio device, I would take a guess that this is coupled with the problem elupus found with SDL Audio constantly feeding the audio device null data when unused instead of closing the device. For now I have thus disabled GUI sounds on Angstrom in my branch and this dropped CPU from 100% to 10-20%.
• I have profiled video playback and it seems that while playing 480p content (Big Buck Bunny) we spend most of the time just idleing, thus the decoding is not CPU bound. Some more testing showed that the yuv to rgb transform seems to make the presentation slow and this is because this transform is done in shader. If we disable the yuv to rgb in the shaders presentation is almost whatchable in terms of frames per second. And as my mentor (Michael Zucchi) and Måns have suggested it seems like OMAP overlay (which can do the yuv to rgb transform in hardware) will help alot.

Plan

• Continue making controls mark their dirty regions. Most importantly make lists mark their region.
• Make the marking handle the 3D case were controls are rotated.
• Buffer control groups using frame buffer objects.

Risks

• Making controls mark their regions is a daunting task, takes quite a while for each control. Lists will be a nightmare and might take lots of time.
• Buffer control groups using frame buffer objects might not save all to much, need to do some testing regarding this but should hopefully be just a question of moving the code I created for using framebuffer for the entire dirty region solution to the control groups (as a test, need to be better abstracted later).
• Using OMAP Overlays might be hard in xbmc? Probably low risk and Måns have a sample app called omapfbplay which code could be taken from.