Libav Summer Of Code 2013
How it works
Google's Summer of Code program is simple: you (the student) work on a project, full-time, during the whole summer, and you get assistance (advice, mentoring) from a seasoned Libav developer who knows the project and has considerable standing in the community. By doing so, you'll learn to operate in an open source project, you'll get relevant coding experience, and you'll have a chance at earning money while doing fun stuff during the summer. So, you need a project, a mentor, a qualification task (see below) so we can quickly assess how good a candidate we feel you'll be for the program, and then you can apply.
Selecting a project
Below, you'll find two lists of projects:
- Projects with a mentor
- Projects without a mentor
If you choose a project with a mentor, talk to that mentor (see below) and select a suitable qualification task. Once completed, you're eligible for participating in our Summer of Code program. If you choose a project without a mentor, your first job is to find a mentor (see below). Then, once you've found a mentor, continue as before. If you don't like any of the projects, you're free to define your own project and find a mentor as mentioned before (see below for caveats).
Once you've found a project (with or without mentor), start talking to the developers of the Libav project. We can often be found on IRC, and you can talk to us on the mailing lists as well. Hop on irc.freenode.net, channel #libav-devel, or mail us at firstname.lastname@example.org. There, you'll be able to ask around for persons to guide you on projects without a mentor if you need to. If you're trying to define your own project, explain (with reasonable amount of detail) what you intend to achieve and why you think your project should be in our Summer of Code program. Once you've found a mentor, you're good to start your qualification task.
Note that the self-selected mentor needs to have considerable standing in the community to be eligible for mentoring. Likewise, if you choose to define your own Summer of Code project, some community members of considerable standing need to vouch for your project.
Your qualification task
The goal of a qualification task is to see if the mentor and student feel that, together, they will be able to finish the project of their choice. More specifically, the mentor will want to test whether the student has the skills and work ethics to complete a large coding project in a limited amount of time. The student will want to make sure that the mentor provides (useful) assistance when necessary. Therefore, students should select a mentor and a Summer of Code project before starting their work on a qualification task. The qualification task is often (but not necessarily) related to the selected project. For example, if your project will be to reverse engineer a new video codec, the qualification task may be to write a partial bitstream parser for that codec. If your project is to write a muxer for a container format, the qualification task may be to write the code to write the stream header.
There will be a second qualification task for every student: Pick a file of moderate size and reformat it in proper K&R style. The goal of this task is twofold: First it familiarizes students with the style that they will have to write their code in, second it demonstrates that students are able to submit patches from Git and go through our review process.
While you're working on your qualification task, apply at http://www.google-melange.com/. The degree (and detail) with which you've finished your qualification task will determine how likely your project is to be selected. In the past few years, students that completely finished their qualification task always got selected as Summer of Code students, but that may vary depending on the number of slots we are allotted by Google, and the number of students that apply.
1st Tier Project Proposals
1st tier project proposals are project ideas that are reasonably well defined AND have a mentor.
Hardware Acceleration API
Libav has two different and incomplete APIs to provide hardware acceleration wrapping. The project should improve the available abstraction, migrate the currently implemented ones and add more hardware acceleration interfaces.
- Draft the API (that will require knowledge of libavcodec).
- Port vaapi/hwaccel to the new API.
- Port VDPAU to the new API.
- Implement Freescale VPU support.
- Implement TI dce support.
Mentor: Luca Barbato
VP9 Native Decoder
The WebM team is refining the evolution of their VP8 codec using a number of additional tools and tunings. The project involves providing a baseline decoder as first step and optimizing it to be at least as fast as the libvpx one on one of the most used architectures (ARM and x86_64).
Mentor: Luca Barbato
WebP Lossless Native codec and WebP Lossy decoder
WebP is a promising image format that could supercede JPEG and PNG as common format for web images, it leverages VP8 for lossy encoding and uses a relatively simple original format for the lossless part.
The project is split in a number of easy tasks, such as writing a decoder for both the lossy and the lossless mode and a much harder task that is providing a good encoder for the lossless part, at least. (Exceptional praise for producing a good lossy encoder but it is not required.)
Mentor: Luca Barbato
Native DVD support
Most of the open source support for DVDs is available through libdvdread and libdvdnav. Currently there is some effort to unify them in a single library (libdvd5). An additional step would be factoring the non-interactive part of into the libav codebase to leverage even more code and leave as stand alone library the parts that require some kind of interaction.
Mentor: Diego Pettenò
Restructuring the MPEG video family of codecs
Many encoders and decoders currently use the MpegEncContext structure and its associated API. This structure is a huge monolithic blob which combines the features of all those encoders and decoders, thus making it very fragile and hard to understand.
The goal of this project is splitting out parts of the MpegEncContext API into self-contained structures that would be easier to grasp, while still allowing code reuse where appropriate.
Mentor: Anton Khirnov