Summer of Code 2015

From XiphWiki
Jump to: navigation, search

This is our ideas page for Google Summer of Code 2015 projects with Xiph.org.

Students please use the template at Summer of Code Applications when applying for a GSoC position.

Mentors please visit Summer of Code Mentoring and help us prepare our application as a mentoring organization.

Introduction

This year Xiph.org is focusing on the Icecast streaming multimedia server for its GSoC participation. Both audio and video live streaming are currently hot topics, especially due to improved HTML5 support for this technology.

Below you'll find the description for the following GSoC project ideas around the Icecast project.

  • Configuration interface
  • Let's encrypt for Icecast
  • Improved WebM support for Icecast
  • Stream directory API
  • Client side for stream directory API
  • DoS mitigation

If you want to know more about a particular idea, please get in touch with the people listed under "possible mentors". While no guarantee, that the person will be the actual mentor for the task, they know it and will be happy to answer your questions.

In addition Trac contains some tickets tagged GSoC that can serve as starting points for developing project ideas.

In our previous participation we focused a lot on our multimedia codec projects. This turned out to be very challenging for students. So this year we're not offering project ideas from those. If you're a student interested in codec work, have previous experience in it and are confident, that you can convince us, you're welcome to get in touch.


Detailed Project Descriptions

These ideas were suggested by various members of the developer community as projects that would be beneficial and which we feel we can mentor. Students should feel free to select one of these, develop a variation, or propose their own ideas. Here, ideally.


Icecast configuration interface

Icecast is very flexible in its configuration and uses XML to store configuration.

Problem / Intro

While we do our best to document things and have a solid default configuration, many users fail at setting up Icecast by e.g. malforming the XML or misunderstanding options.

Solution / Task

The Icecast project should have its own reference configuration UI. It should expose all possible configuration options. It should have several detail levels to make it easier for users. Easy with only core items, up to Expert exposing all items. Either from scratch or by adopting existing open source code.

ticket on this topic

Requirements

The student should be familiar with XML, c programming and HTML.
The task, although seemingly easy is considered hard and high workload, also it requires cross-domain knowledge to work on front and back end.

Possible Mentors

Thomas B. Rücker, tbr



Let's encrypt for Icecast

Icecast supports HTTPS through openSSL. The Let's encrypt project will offer automated and free certificates.

Problem / Intro

Configuring Icecast is challenging, doing it for SSL adds a layer of complexity. Problems like correct hostname configuration, certificate preparation become an additional deployment burden.

Solution / Task

Integrate with or create a derivative of the Let's encrypt agent. Take into account specific challenges, such as determining the correct and intended DNS name (hostname) of the Icecast server.

Requirements

The student should be familiar with Python. Familiar with and running Ubuntu (native or in a virtual machine), due to upstream development target.
It is considered a medium difficulty task, as it is mostly about one aspect and with a well developed API on the other side.

Possible Mentors

Thomas B. Rücker, tbr

Gilles Pietri, Gilou


Improved WebM support in Icecast

Icecast supports WebM live streams since version 2.4.0 enabling many interesting HTML5 use cases.

Problem / Intro

While WebM support is solid, it is rather limited. For Theora streams we extract information from the stream about resolution and other parameters.

Solution / Task

  • Dive into the EBML/Matroska/WebM format, reliably extract the necessary data, make it available as part of the Icecast metadata structure.
  • Investigate and implement ways to splice WebM streams reliably to enable transitions between streams that have sufficiently close/identical parameters.
  • Verify support of VP9/Opus in WebM
  • Verify and improve support of audio only WebM

Further information can be found by looking at the tracker tickets and it's dependencies:
https://trac.xiph.org/ticket/2155

Requirements

The student must know C and either have previous EBML experience or demonstrate the ability to learn it before being approved. This is due to the high risk of failure we see otherwise.
It is considered a very difficult task, as it touches on container formats and codec parameters.

Possible Mentors

Thomas B. Rücker, tbr nn


Stream directory API

For live streams Xiph.org operates a directory, mainly used by Icecast. It lists tens of thousands of streams.

Problem / Intro

The old directory only exposes a XML export of most of the database as the closest thing to an API. A lot of listener software uses this XML, but would benefit from a server side search. We've been experimenting with exposing a feature rich JSON API, but then decided to rewrite the directory code from scratch.

Solution / Task

The rewritten directory needs a well designed API with a performance optimized and robust implementation that integrates with listener software, it has been set up in a way that will make this sufficiently easy. The API will need to be tested.

Requirements

The student should be familiar with nodejs, SQL (in particular Postgres) and JSON (both generating and consuming).
API design knowledge would be appreciated, but we have that also in the core team.
This task can be fairly easy, but depending on the student's capabilities can be scaled to medium.

Possible Mentors

Thomas B. Rücker, tbr
Marvin Scholz, ePirat


Client side for stream directory API

For live streams Xiph.org operates a directory, mainly used by Icecast. It lists tens of thousands of streams.

Problem / Intro

The old directory only exposes a XML export of most of the database as the closest thing to an API. A lot of listener software uses this XML, but would benefit from a server side search. We've been experimenting with exposing a feature rich JSON API, but then decided to rewrite the directory code from scratch. We are designing and implementing a JSON API (possibly also as part of GSoC), but will need client software to use it.

Solution / Task

To start the student will need to find as many open source consumers of the old XML API as possible and also open source players that don't have Icecast directory support yet, but would benefit from it. Then after agreeing with us on a short list of software, depending on the students knowledge of programming language used and client software popularity, implement new directory support for those players (at least one, possibly more if time and complexity allow).


Requirements

The student should be familiar with JSON, the HTTP protocol and at least one major programing language (preferably C; if other show, that there are possible target projects written in that language).
Difficulty of this task will depend on the chosen player project, but we're expecting it to be in the medium to even hard range.

Possible Mentors

Thomas B. Rücker, tbr


Investigate URL-Auth (D)DoS Mitigation Possibilities

Icecast is very flexible in its configuration and allows authentication to be delegated to a backend server. This server has to accept and answer connections in a fast and reliable manner.

Problem / Intro

While we do our best to test things and do quite a bit to harden the mentioned process there are certain risks to be evaluated in regard of:

  1. Server load - Icecast and Backend Server
  2. Timeouts - What happens when the Backend does not answer inside the timout window?
  3. Responsiveness - What happens if a Icecast server has to wait on many Backend requests to finish?
  4. (if implemented by then) TLS Client Cert Auth - TLS Client Auth gives us quite some more possibilities for URL-Auth

Solution / Task

To start the student should familiarize themselves with the URL-Auth system and then investigate the above problems. Patches for identified issues and improvements for optimizing and enhancing the default behaviour should be the primary output. As a side effect it should result in best practices for configuring url-auth reliably.

Requirements

The student should be familiar with the HTTP protocol (versions 1.0 and 1.1), the C programming language and also with stress-testing.
The task also requires imagination and the ability to develop own innovative approaches to testing certain aspects. It is not suitable for students who require a lot of exact steps and guidance. Workload can be scaled in agreement with the mentor, by leaving out certain aspects.

Possible Mentors

stephanj
Thomas B. Rücker, tbr

See Also