Archive:Google Summer of Code/2013
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 April 22nd to May 3rd, 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.
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, designed around the 10-foot interface (living room) environment. 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 40 languages. For more information, see the page XBMC Media Center.
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's new PVR functionality
XBMC is written primarily in c++ and runs on a variety of platforms including Android, iOS, Linux, OS X, and Windows. It has been ported to work on several low-power platforms including the BeagleBoard, PandaBoard, AppleTv, AppleTV2, the Raspberry Pi, and most recently Android.
XBMC was a mentoring organization in 2008 and 2012, and had team members involved in GSoC for other projects in 2011.
If XBMC is selected as a mentoring organization for 2013, 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.
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
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.
- 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 PROJECT TITLE GOES HERE
- 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 a distributed 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, and Android) 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 was to focus on the "client/server" model. That goal has been extended this year to one where every instance of XBMC can act either as a client or a server, so that the XBMC ecosystem can act more as a distributed network, meaning, for example, your HTPC can direct and update your tablet, and your tablet can direct and update your HTPC.
Other projects that don't fit in this category but may still be of interest to students are listed in the last section. And needless to say, students are more than welcome to completely deviate from this focus. Great new ideas are always welcome.
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 (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 database layout - The existing SQL database layout for music and videos is steeped in history, not all of it good. The layout is non-optimal for the storage system that XBMC needs for data. The need is for a fast store from which movie information can be retrieved. It's mostly static information, and there's a lot of interlinked information (m:n maps) that need to be associated with each item and displayed when a list is fetched. i.e. either the information is grabbed in a single query, whereby you have a bunch of unnormalised data (e.g. a list of genres for each movie item) or the information is grabbed through multiple queries per item, whereby you can have everything nicely normalised. A hybrid solution might be best - some work has been started on this as part of garbear's piccture library project, such as this branch. Various other suggestions and notes are available on the forums and wiki.
- Improved UPnP serving and client - XBMC includes a UPnP server and client. Last Google Summer of Code, much of the project of sharing metadata available in XBMC libraries was completed; however, a long road lays ahead for the UPnP server and client. This project would fill in the gaps, 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) and potentially even transcoding content where appropriate. Any such improvements would be available transparently to listings other than UPnP (eg addon listings) by setting the appropriate properties.
- 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 or iOS remote control, and extending the JSON-RPC API and/or UPnP server for any additional requirements, including server transcoding, remote control playback, using the remote as a local audio stream for quiet watching/listening with headphones, or even copying transcoded files locally for future playback.
- 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.
- 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 Improved support for Linux windowing systems
XBMC's EGL implementation was recently overhauled to allow for dynamic detection of the current window system, so that a single binary can be used everywhere that EGL is supported. However, since this work was done, no new windowing systems have been added. A student may wish to work on support for one or more of these. Work may also include further abstraction of our current windowing and input implementations. Possible windowing systems for consideration include:
- Wayland. This would require a matching input implementation as well.
- X11. As GLX is semi-officially deprecated, dynamic EGL replacement would be very valuable moving forward.
- KMS/GBM: A barebones framebuffer implementation for drivers supporting KMS.
- Mir: If sufficient documentation exists, this could be a consideration as well.
This work would mainly benefit ARM devices in the future, as it would mean that distributions would be able to provide a single binary capable of running in any graphical environment.
The current EGL interface is well abstracted and documented, with 3 working implementations for use as reference. Further, there are proof-of-concept interfaces for X11 and KMS that could be provided to a student.
3.5 Other projects of interest
- Improved Picture Player - Write a new picture/slideshow engine to be more like a normal player (see [VideoPlayer|[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 - 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.
- Offline Content - Add the ability to mark media from the database to be available offline. The use case for this is - someone with a mobile device (for example ipad or android tablet) wants to go for vacation or whatever and just wants to watch some media from his db when away from home. Part of this feature would be the easy selection/marking of offline content and then transfering it to the device where the xbmc instance is running. Bonus would be some sort of offline db so that the experience during traveling is as fancy as on the home network.
4 Students Project Proposal Ideas
Feel free to add of your own ideas for projects on this page or on the XBMC GSOC 2013 forum. They can be as big or as small as you feel you can comfortably accomplish between June 17th and September 16th. In the end, it's better to have a smaller, completed project, rather than a larger, incomplete project.
To submit a proposal idea:
- Copy the text from here. Do not save it in that window, just copy the text
- Paste the text into this section by clicking here.
- Fill out everything using your specific proposal.
4.1 Video effects
4.2 Mobile mode
4.3 Expand boblight support
4.4 Miracast Support
4.5 XBMC Media Databases for handling metadata across multiple systems
4.6 music control function with headphones
- Name: Kateryna Narozhnaiy E-mail: dayly95 (AT) gmail (DOT) com
- About me I am currently a student of Ukrainian State Academy of Railway Transport, department of Specialized Computer Systems.
- Summary: I want to implement a music control function with headphones via the audio player XBMC. For example, when we travel by public transport, it is not convenient to switch to music, switch play lists and so on. I want to create a function that will manage music with special commands (by click).
I think that XBMC community will have great benefits from this project, such as:
1. Because nowadays there are a lot of various applications of media players, it is the ease of operation will determine the user's choice. Increased number of users profitable company.
2. A significant drawback is a small functionality, when smartphone is in the pocket. Increase functionality will attract new users, which is advantageous the company.
3. Using my app company does not need produce additional equipment. It will allow increasing the number of users.
4. Perhaps by the result our common work, the company will be able to issue a patent. I am ready to discuss the transfer of the rights of my intellectual property with company on mutually beneficial terms.
I want to complete particular this project because I'm really exciting on media — music, videos.
Also I need sometimes this. Now I have a chance to do it and to help others.
- How will I achieve this:
- What will the project focus on:
- What does it touch in XBMC:
- Possible mentors: