Archive:Google Summer of Code/2012

From Official Kodi Wiki
Revision as of 23:54, 15 August 2021 by RogueScholar (talk | contribs) (Came to remove the Google PlusOne template, stayed to correct all the atrocious use passive voice and inability to spell simple words, hahaha)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Notice This page describes a previous year's event. For the most recent GSoC page please visit the Google Summer of Code category.

Welcome to the XBMC Google Summer of Code 2012 Ideas page. We are very pleased to announce that we have been accepted as an official GSoC 2012 Mentor Organization.

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’re interested in covering.

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 together according to the published GSoC 2012 Timeline of Events.

About Us

As there may be many students who will land 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.

=== Through the eyes of our users To get an idea of what XBMC is truly capable of, it really must be seen with one's own eyes. Here are a few user-created videos that offer some insight into what our users experience when they use XBMC:


XBMC with the default Confluence skin
XBMC with Aeon Nox skin

XBMC on Raspberry Pi

XBMC is primary written in C++ and runs on a variety of platforms, including: Windows, Linux, MacOS, and iOS. It has also been ported to work on several low-power platforms, including the BeagleBoard, PandaBoard, AppleTV/AppleTV2, and most recently, the just-released Raspberry Pi Model B.

XBMC was a GSoC 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 (of course) welcome to propose ideas that are not on the list, too, and are encouraged to be as creative as they like.

Mentors

This years main mentors are Jonathan Marshall (jmarshall) and spiff, both of whom have been mentors in previous GSoCs. Serving as backup mentors will be Joakim Plate (elupus) and Bob van Loosen (bobo1on1). The GSoC admin is Nathan Betzen (natethomas), and other team members have already volunteered to be available to assist where and when possible with code and design reviews.

All mentors and backup mentors are extremely experienced in the XBMC codebase and will thus be able to assist students in quickly familiarizing themselves with it and quickly identifying projects that are both achievable for someone who is unfamiliar with the internal workings of XBMC and provide value to the wider XBMC community.

Project Proposals

Overview

Qualifications for a good Summer of Code proposal include:

  • A discrete, well-defined modular
  • Being organized around a series of measurable sub-goals
  • Is based on complete, open specifications that are available free-of-charge

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

An example of a less-desirable proposal is something that's inherently subjective and thus 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 reiterate:

  • Localized/isolated code projects == good
  • Global code refactoring == bad
  • A project should have a set of sub-goals, so even if the ultimate goal proves to be too big, some of the parts will still have been beneficial

Most of all, it needs to have a planned scope that errs on the side of realism and isn't too big! This is an very important consideration when choosing a project, and while it's fun to think about accomplishing a grand project, it's not always feasible. We don't want anyone's summer to end with the feeling that they came up short, rather when autumn is upon us we want you to be showing people the things XBMC can do then that it can't now because you were involved! It's simply better to finish a smaller project than to have to abandon a grand one before it's complete.

Template outline for proposals

Your 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 I will achieve this
Explain how the project will be done, what technologies are needed and how to implement them.
What is the project's focus
Explain what the project will focus on, and what the important constituent parts of the project are.
Benefits
Who will benefit from this project and why? 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 ultimate goal of the project? A project may not always solve the entire problem, as you may eventually be confronted with learning that it would take more time than you have. Think hard about what can be accomplished during a summer with your skills and then imagine you're 20 years older and have already learned well that it is equally likely for you to only accomplish half of that as it is that you'll finish what you expect to be able to. If a project doesn't in fact get completed during your time working on it, it would've been better to have keep looking for one that was just as rewarding but offered smaller or more plentiful subgoals.
How widespread are the changes to the codebase?
Think about what parts of the code this may touch? XBMC is a large application, and a lot of the code for individual features is distributed throughout several locations and very complex. If a project touches too much, it may be impossible to complete.
Requirements
What is needed to complete the project? What code languages are involved? What tools and skills are mission-critical? Does specific hardware need to be available for testing during development?
Possible mentors
We'll use this section to share with you who we think would be well-suited as possible mentors

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, and other OSes still in the works), more and more folks are accessing both local and remote media from multiple machines. It makes sense for us, therefore, to keep information about what content is available from where and what parts have already been watched synchronized across multiple clients. Our primary goal for 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 final section below.

Current state of XBMC's capacity for client/server setups

XBMC already contains several features that allow for client/server interaction, these include:

  • A UPnP server and client built-in
  • The JSON-RPC API for bi-directional information exchange
  • The EventClient API for bi-directional remote control communication
  • MySQL server support for sharing XBMC's music and video library 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 (i.e. MySQL server) or don't yet perform everything required for true client/server communication (i.e. UPnP doesn't share all metadata and 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.

Possible proposals within the client/server area =

Improving UPnP server and client

XBMC includes a UPnP server and client that provide the ability for all of the media files in each instance to be shared over the UPnP interface, but they don't expose all of the metadata available about them within those libraries. This project would fill the gaps of missing metadata, as well as ensuring that niceties such as resume bookmarks and the like are transferable seamlessly from client to client. In addition, the interaction between client and server would be enhanced to allow either of them to update watched statuses, resume bookmarks and similar details, as well as allowing on-client editing of metadata, which then propagates to the server (either using UPnP methods or the JSON-RPC interface). Any such improvements would be available transparently to listings other than UPnP (e.g. add-on listings) by setting the appropriate properties.

Refine scraper 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 scraper 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 (e.g. CreateNfoURL, CreateSearchURL, GetDetails, GetArtwork, etc.) along with any helper functions they'd need (callbacks to fetch URLs, etc.), implementing a simple example of use of the API (in C/C++), followed by a wrapper for the existing XML/Regex scrapers, and then adding Python bindings with pro forma Python scrapers. The intention would be for most of this work to be done outside of the main XBMC codebase and then get integrated into XBMC when complete and stable.

Improve remote clients for mobile/touchdcreen devices

Design and implement a remote client for touchscreen-based devices (Android and 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 as well as extending the JSON-RPC API and/or UPnP server for any additional requirements.

Improve support for multiple profiles within the server APIs

Currently XBMC has a profile system whereby multiple users can interact with the XBMC client while sharing the same libraries. These are currently stored outside of the main database, which makes interactions with XBMC that require using a particular profile troublesome. In particular, watched counts, resume points, and 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 approach would involve the profiles being stored inside the main database (or at least a representation of them) and allowing content and its metadata (play counts, resume points, and 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, television shows and music videos are currently fixed. This project would look to extend them to accommodate user-specified content categories. One potential extension is adding a content type column to each of the existing content tables to allow 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 later edits it) 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 categorization could be made by the addition of generic key/value tables to allow for this information to be extensible. 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 (e.g. in the thumbnail loader) for main listings, then joined to the table for later filtering (a/k/a smart playlists).

Extend skinning engine to better support touch interfaces

With tablets and other touchscreen interfaces being used much more widely, it makes sense to define UI controls that better interact with these devices. In particular, a drop-down list box (a/k/a combobox) would be an ideal addition that would benefit touch devices as well as non-touch ones. Furthermore, the addition of buttons attached to items in lists would be useful to serve as hints for additional menu options available to the user, most of which are currently hidden inside the context menu and thus not discoverable, or at best clumsily available via menus that regularly pop-up when the user taps an item. Looking ahead, 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 3:2 or 4:3 aspect ratio interfaces, whereas modern televisions are typically 16:9 or even 21:9. Having the flexibility for layout/scaling and positioning of the skin to be done on a control group basis rather than defined at the window layer would allow interface element groups to automatically reposition their content to better align with the screen real estate made available by each 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 interface designers 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 skin designers must choose between static content they define themselves or dynamic content supplied by XBMC over which they can exert no control. This project would look to add a third option whereby the skinner specifies that they want the list populated with, for instance, a particular content type from the filesystem or from XBMC's libraries. XBMC would then retrieve the list and any metadata and populate it in the background. Building on that, XBMC would then apply it's default actions for that list (interfacing with the skin as needed) when the user interacted with that information (e.g. playing a music file when the user selects it).

Photo Library

Design and implement a database schema suitable for storing and retrieving photo metadata, where fields should consist of the typical datapoints found in such files (e.g. EXIF tags), along with an extensible key/value field system to allow for tagging, adding keywords, defining people that are depicted, etc. Support should include the ability to identify when new pictures have been added to the user's filesystem or when metadata information has changed for one or more photos. Design and implement a filter/directory node system that allows the user to browse/search this information and the system to generate smart filters and slideshows. Lastly, add support for such filters to the photo library UI.

Other projects of interest

Games / Applications Library (Medium Difficulty)

Add functionality similar to the current video and music libraries for games / applications. Add a game / application executable or a folder of ROMs for emulators, then parse files for tags and other metadata along with file paths in a database and possibly scrape sites for any missing details.

Automated Test Suite (High Difficulty)

Devise a mechanism for defining and executing automatic regression tests of XBMC features.

Improve Photo Library Presentations (Medium Difficulty)

Write a new photo slideshow engine to be more like a normal player (see DVDPlayer and PAPlayer as examples). An ideal solution would be to utilize the existing GUIImage code to handle loading of images and have the animation engine handle transition effects (pan, zoom, rotate, etc.)

RSS Reader ((Medium Difficulty)

Create an add-on which works much like Google Reader/Feedly, that supports parsing text, video and images from multiple RSS feeds and displays this in the GUI. This should be simple enough, like the RSS readers on most mobile devices, but adaptable for a televsion-sized display as well.

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.

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.

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

Looking back

Retrieved from "https://kodi.wiki/index.php?title=Archive:Google_Summer_of_Code/2012&oldid=232946"