Google Summer of Code 2012

OUTDATED: This page describes last years event. For the 2013 Google Summer of Code please go here: Google Summer of Code 2013

Welcome to the XBMC Google Summer of Code ideas page. We are pleased to announce that we have been accepted as an official GSOC mentor organization this year.

We encourage interested students to review some of the ideas on this page, and then feel free to provide input on any ideas you may have in the Student Project Proposal area. Alternatively, feel free to jump into the XBMC GSoC subforum and chat about any project you’d love to cover.

From March 26th to April 6th, any interested students may apply at the GSOC home page to work with XBMC. After that, we’ll notify applicants whether we get to work with each other according to the GSOC schedule.

Contents 1 About Us 1.1 Mentors 2 Project Proposals 2.1 Overview 2.2 Outline for proposals 2.2.1 Some project title 3 Team-XBMC proposal ideas up for discussion 3.1 Focus on client/server model 3.2 Existing ability within XBMC for client/server setups 3.3 Projects within the client/server area 3.4 Other projects of interest 4 Students Project Proposal Ideas 4.1 Input Generalization 4.2 Media Server

1 About Us

As there may be many students who have landed here as a result of GSOC, but are unfamiliar with the project, here are a few resources that may help explain what we are about.

XBMC is an award-winning free and open source (GPL) software media player and entertainment hub for digital media. Created in 2003 by a group of like minded programmers, XBMC is a non-profit project run and developed by volunteers located around the world. More than 50 software developers have contributed to XBMC, and 100-plus translators have worked to expand its reach, making it available in more than 30 languages.

To get an idea of what XBMC is truly capable of, it really must be seen. Check out a few other user-created videos:
XBMC with the default Confluence skin
XBMC with Aeon Nox skin
XBMC on Raspberry Pi

XBMC is written primarily in c++ and runs on a variety of platforms including Windows, Linux, OSX, and iOS. It has been ported to work on several low-power platforms including the BeagleBoard, PandaBoard, AppleTv, AppleTV2, and most recently, the Raspberry Pi.

XBMC was a mentoring organization in 2008, and had team members involved in GSoC for other projects in 2011.

If XBMC is selected as a mentoring organization for 2012, students will need to review the Overview of a good project proposal, follow the outline for proposals when applying, and review the list of project ideas detailed below. Students are welcome to propose ideas outside the list and are encouraged to be as creative as they like.

1.1 Mentors

This years main mentors are Jonathan Marshall (jmarshall) and Arne Morten Kvarving (spiff), who have both been mentors in previous GSoCs. Backup mentors are Joakim Plate (elupus) and Bob van Loosen (bobo1on1). The GSoC admin is Nathan Betzen (natethomas). Other team members have also volunteered to be available to assist where possible with code and design review.

All mentors and backup mentors are extremely experienced in the XBMC codebase and will thus be able to assist students in getting to know the codebase and in quickly identifying projects that are both achievable for someone unfamiliar with the internal workings of XBMC and desirable to the wider XBMC community.

2 Project Proposals

2.1 Overview

Qualifications for a good Summer of Code proposal:

• Discrete, well-defined, modular
• Comprised of a series of measurable sub-goals
• Based on open specs that are available free of charge
• Based on complete specs

An example of a good proposal is the implementation of a new feature or function that is not yet available in XBMC.

An example of a less desirable proposal is one that's not as measurable, such as refactoring an existing API. Bad proposals tend to be ones that would require touching a lot of core code.

To re-iterate:

• Localized/isolated code projects = good
• Global code refactoring = bad
• A project should have a set of subgoals, so even if the end goal turns out to be too big some of the parts will be of benefit.
• Not too big! This is an important problem when choosing a project, while it is fun to think about solving a grand project its not always realistic. Its better to finish a smaller project than to start a grand one.

2.2 Outline for proposals

2.2.1 Some project title

• Summary: A somewhat small but explanatory walk through of the project. It should not be overly detailed just enough to understand the problem trying to be fixed and how this project opt to solve it.
• How will I achieve this: Explain how the project will be done, what technologies are needed and how to implement them.
• What will the project focus on: Explain what the project will focus on, what is the important parts of the project.
• Benefits: Who will benefit and why from this project. Think about what a user or developer may need or do to benefit from it. Why does it benefit many users.
• Goals: What is the goal of the project, a project may not always solve the problem entirely as it may take to much time. Think hard about what can be accomplished during a summer with your skill and deduct that quite a bit. If the project can't be done after this perhaps its better to opt for a smaller one or one with subgoals.
• What does it touch in XBMC: Think about what parts of the code this may touch, XBMC is a big application and a lot of the code is spread out and very complex. If a project touches to much it may be impossible to complete.
• Requirements: What is needed to complete the project, what code language knowledge what hardware etc.
• Possible mentors: Place to add possible mentors (Team-XBMC will add this).

3 Team-XBMC proposal ideas up for discussion

3.1 Focus on client/server model

For this year's GSoC, XBMC will be focusing on projects related to making XBMC easier to use in environments where multiple XBMC clients need to interact. With XBMC running on tablets and new embedded devices (iOS, rPi, with other OSes in the works) more and more folk are accessing both local and remote media from multiple machines. It makes sense, therefore to keep information about what content is available and what has been watched in sync across multiple clients. The primary goal of GSoC 2012 is to focus on projects that make this easy for the user to accomplish. Other projects that don't fit in this category but may still be of interest to students are listed in the last section.

3.2 Existing ability within XBMC for client/server setups

XBMC contains several features that allow for a client/server setup. These include:

• A UPnP server and client built-in.
• The JSON-RPC API for two-way passing of information.
• The EventClient API for two-way remote control communication.
• MySQL server support for sharing XBMC's music and video databases, with path translation services for sharing across different machines.

While these are each useful, they're typically either difficult for the user to setup (mysql server) or do not quite contain everything required for true client/server communication (UPnP doesn't share all metadata, editing isn't available from the client etc.) With some focused projects in this area, the user experience of XBMC across multiple clients/servers would be dramatically improved.

3.3 Projects within the client/server area

• Improved UPnP serving and client - XBMC includes a UPnP server and client. Not all of the metadata available within XBMC's libraries, however, are shared over the UPnP interface. This project would fill the gaps of missing metadata, as well as ensuring that niceties such as resume bookmarks and the like transfer seamlessly from client to client. In addition, the interaction between client and server would be enhanced to allow the client (or server) to update watched status, resume bookmarks and the like as well as allowing on-client editting of metadata which then updates the server (either using UPnP methods or the JSON-RPC interface). Any such improvements would be available transparently to listings other than UPnP (eg addon listings) by setting the appropriate properties.

• Clean scraping API with bindings to python - Currently XBMC uses regular expressions to handle the parsing of websites, and the existing scraper API is focused on this end use. Designing and implementing a new scraping API that is language-agnostic will allow alternate bindings to be provided, for example to python. Work would involve identifying the main entry points to scrape (eg CreateNfoURL, CreateSearchURL, GetDetails, GetArtwork etc.) along with any helper functions (callbacks to fetch URLs etc.), implementing a simple example of use of the API (in C/C++), then implementing a wrapper for the existing XML/regexp scrapers, and then adding python bindings with example python scrapers. The intention would be for most of this work to be done outside of the main XBMC codebase, with integration into XBMC being done as a last task.

• Improved remote clients for tablet/touch devices - Design and implement a remote client for touch-based devices (Android, iOS) that interact with the main APIs that XBMC provides for client apps (JSON-RPC and UPnP server). This may involve building on the existing Android remote control, and extending the JSON-RPC API and/or UPnP server for any additional requirements.

• Better support for multiple profiles within the server APIs - Currently XBMC has a profile system whereby multiple users can interact with the XBMC client and share the same library. These are currently stored outside of the main database, which makes interacting with XBMC using a particular profile troublesome. In particular, watched counts, resume points, ratings etc. are forced to be shared between profiles, and the only filtering of content is done based on which filesystem locations the profile is allowed access to. A better system would involve the profiles being stored inside the main database (or at least a representation of them in the database), allowing content and meta information related to the content (playcounts, resume points, ratings) to be linked to one (or more) of those profiles. In addition, specification of which profile is accessing JSON-RPC/UPnP would then allow those services to offer just the content information that the profile has access to.

• Custom library categories - XBMC's library categories of Movies, TV Shows, MusicVideos are currently fixed. This project would look to extend this to user-specified content categories. One potential extension is adding a content type column to each of the existing content tables, allowing simple queries for subsets of rows. The content type and category would be a source-level attribute, defined when the user first adds a filesystem source (or edits a source) to XBMC (e.g. type is TV Shows, category is Anime). XBMC would then show Anime and TV Shows as general categories (TV Shows being of type TV Shows and empty category). Additional support for further categorisation could be made by the addition of generic key/value tables to allow for extension of information. Without altering the existing tables, this could be done with an (idContent,idType,idKey,strValue) style table, supplemented with an idKey, strKey match. Additional database fetches for this table could then be done off-thread (eg in the thumbloader) for main listings, with joining to the table being done for filtering (smartplaylists).

• Extend skinning engine to better support touch interfaces - With tablets and other touch interfaces being used more and more, it makes sense to define UI controls that better interact with these devices. In particular, a drop down list box (combobox) would be an ideal addition that would benefit touch devices (and non-touch devices). In addition, the addition of buttons attached to items in list would be useful to serve as hints for additional menu options available to the user, most of which is currently hidden behind the context menu (not discoverable), or clumsily available via always-popping up menus when the user taps an item. Further, the potential for XBMC scaling panel or list controls using multi-touch zooming would be useful to explore.

• Extend skinning engine to better support multiple layouts - Many tablets are 3x2 or 4x3 interfaces, where as televisions are typically 16x9 (or even 21x9). Having the layout/scaling and positioning of the skin being done on a controlgroup basis rather than being defined at the window layer would allow groups to automatically reposition their content to better align with the aspect ratio of the users' device. For example, aligning a group to the center of it's parent, while ensuring it doesn't stretch would allow information to remain in the middle of the screen regardless of aspect ratio. Other improvements would be to allow relative control positioning (i.e. control <foo> should be positioned 10 units to the right of control <bar>) which allows the skinner to both more easily prototype and skin as well as making it easier to alter.

• Extend skinning engine to allow populating lists/panels with filesystem content - Currently skinners must choose between static content, defined by the skinner, or dynamic content filled by XBMC over which they have no control. This project would look to add a 3rd option, whereby the skinner specifies that they want the list filled with particular content from the filesystem or from XBMC's libraries. XBMC would then retrieve the listing and any metadata and populate the list (all in the background). In addition, XBMC would then apply it's default actions for that listing (with interaction to the skin as needed) when the user interacted with that listing (eg playing a music file when the user clicks on it).

• Picture Library - Design and implement a database schema suitable for storing and retrieving picture metadata. Fields should consist of the typical fields found in picture files (eg EXIF information) along with an extensible key/value field system to allow tagging/keywords/people etc. Support should include the ability to identify when new pictures have been added to the users' filesystem or when metadata information has been changed for one or more pictures. Design and implement a filter/directory node system so as to allow the user to browse and search this information, allowing smart filtering and smart slideshows to be generated. Lastly, add support for such filters to the picture window.

3.4 Other projects of interest

• Games / Program Library - Medium Difficulty - Add functionality similar to the current video and music library for a games / programs. Add a game / program executable or a folder of roms for emulators. Parse files for tags and other metadata. Store paths and metadata in a database and possibly scrape sites for more information.
• Automated Test Suite - Difficult - Devise a mechanism for defining and executing automatic regression tests of XBMC features.
• Improved Picture Player - Medium difficulty - Write a new picture/slideshow engine to be more like a normal player (see DVDPlayer and PAPlayer as examples). Ideal would be to utilize the existing GUIImage code to handle loading of images, and the animation engine for transistion effects (pan/zoom/rotate, etc.)
• RSS reader - Medium difficulty - Create an addon which works much like google reader that supports parsing text, video and pictures, (supporting multiple RSS feeds), and displaying this in the GUI. This should be simple enough, like the RSS readers on mobile devices, but suited for a TV display.

4 Students Project Proposal Ideas

Feel free to add of your own ideas for projects here. They can be as big or as small as you feel you can comfortably accomplish between May 21st and August 20th. In the end, it's better to have a smaller, completed project, rather than a larger, incomplete project.

4.1 Input Generalization

Currently in XBMC input is handled very differently depending on the control and each input type is isolated and added as extra and the code have become quite a bit unmaintainable. This leads to a large number of regression bugs and a large number of inconsistencies between the input types. Some bugs are almost unfixable as it is really hard to follow what is going on and even harder to know what is supposed to go on.

As such I propose a clean general input layer where every input type is handled the same way and an input device is made up of a number of smaller, much easier to define, types of input.

The idea is the following: We have many input devices on the system, each input device have an ID which is used when mapping to an action. An ID is for example "wiiremote" or "mceremote". Of course one could add that an input also have a UUID so multiple input devices of the same ID can exist and can be used in games, but this is another matter and the abstraction soon to be explained should be able to handle that addition. Each input device can send Input events to the Input manager, which resides in the core. An input event could for example be that a button is down/up or that a cursor have been moved to a new location. It can also state that an analog location have been moved. Further abstraction would be that an analog location is what a mouse cursor is, however it may make sense to separate those.

As it is currently in code a joystick button is not handled the same as a keyboard button or a remote button, not even a mousebutton. Essentially all button triggers should be processed in the same method and it does not really matter what input device triggered them.

For example a keyboard would be an input device with ID="keyboard" and could send that button="A" is down. Another input device could send ID="WiiRemote" and button="A" is down. Since ID is not the same these are not considered the same remote and the mapping can be different.

So every input on a system becomes an input device, each device can send input events which consist of the ID of the remote and information about the actual event. This event can reflect a button state change or a cursor change.

XBMC Core will then take the input event and map it depending on the ID and the actual event along with a window to create an action. This almost what is done now but currently the code is not general and not shared among the input types.

When we have a general input layer it would be possible to allow jsonrpc to act as an input but also create input addons.

4.2 Media Server

• Summary: It becomes increasingly popular to have more than one instance of XBMC in a household, even more so with the introduction of XBMC on portable devices. This means that sharing the library between XBMC instances becomes much more important to the average user and the current model of doing this via MySQL, while it works, is not user friendly nor future proof. I propose as a project to take core features of XBMCs incredible media management and make them available in a seperate server instance. Note that this does not enforce a client server model and I am not proposing a move to a client server solution, XBMC will and should always have the possibility to run as a stand alone instance fully in charge of its data, this is one of the most important features which most other media centers does not have and it makes XBMC a very user friendly application. What I am proposing is merely the possibility to have XBMC act more like a thin client, i.e. if a server exist on the network its transparently added and feels like it is integrated in client. Instead of doing the sharing over MySQL the data could be shared over uPnP, afterall uPnP is made to share libraries. This would also make other media devices, which is not power by XBMC, able to use said features. The features which makes XBMCs media playback and presentation so great are amongst other things our VFS and scrapers, coincidentilly these parts of XBMC are those which have had quite a bit of feature creep and could use some sanitizing. What I propose is to create small isolated libraries, tested and designed outside of xbmc. The media server would thus be a way to actively test the libraries and hopefully spot problems in the API before they get adopted. When the libraries are considered in a clean state they could be used inside XBMC aswell (not part of this proposal though). The code which is sane in XBMC can obviously be ported over, no need to reinvent the wheel. This does allow for an interesting possibility to clean up our API and make these features available for more than just XBMC with the nice sideeffect of creating a media server!
• What will the project focus on: XBMC, while amazing has quite a bit of feature creep and much of the functionality in XBMC is not as isolated as they could be. Since this project will take a lot of the technologies from XBMC it have the chance to create a set of libraries which are clean, reusable, isolated, designed outside of XBMC and used outside of XBMC. Some of the libraries which could be created as a part of this project is a VFS, scanning and scraping, URL and database libraries. When the project is done these libraries can be used in XBMC (or any other project) if wanted. The media server will act as a testbed for the libraries which are created whilst creating something of use for end-users of XBMC.
• Benefits: From the users perspective they install the media server on his / her computer or server and the HTPC picks up the server and use it. If a friend pops by with a laptop with the server as soon as it enters the network the HTPC can use the content available on said laptop. Another scenario would be that the user have more than one XBMC installation, perhaps on his portable device or just many HTPC boxes. When adding a movie to the server all of these devices will pick it up and if one device watch the movie it is shared amongst them. The project will create a set of reusable libraries which allows which can be used by XBMC which could lead to a cleaner and more stable core, and a way to test functionality outside of XBMC.
• Goals: Create reusable and clean libraries for VFS, database, scanning, scraping and media database.
• What does it touch in XBMC: Nothing, it will require pulling technologies from XBMC
• Requirements: C/C++ for the libraries to be created but Python for the server.
• Possible mentors: jmarshall, spiff