Google Summer of Code
We're looking for students interested in getting involved and making some serious contributions to PiTiVi and GStreamer this summer. See this page to learn why contributing to PiTiVi is the most awesome way to improve your skills. Also take a look at the Main Page of this wiki for various links to help you get started as a contributor.
The "Summer of Code" program is held by Google. Students are encouraged to post applications detailing the coding project you want to do for PiTiVi on the mailing list, and then discuss it with the devs on IRC to strengthen and clarify the goals and implementation details.
What's your style?
PiTiVi is a very modular video editor, whose architecture heavily depends on technologies like GES and GStreamer. Due to our "upstream first" approach, the scope of most GSoC projects will span multiple technologies and codebases:
- PiTiVi, which is the user interface written in Python that integrates everything below. For those who love design, animation, graphical user interaction and testing.
- GES, the "core" logic/engine that powers PiTiVi and other applications for editing. Written in C. For those who wish to bridge the worlds by providing an easy to use library for audio/video editing.
- GStreamer, for low-level work (such as improving filters/effects, codecs, hardware decoding/encoding acceleration, analysis, etc.). Written in C. For those seeking a challenging audio and video experience where optimization is key.
To help you, for each project idea listed on this page, we provide an estimate of the involvement in each of those three areas. For example, a project that is heavily dependent on UI work and a little bit of backend work could look like this:
- ◼◼◼◼◻ Pitivi
- ◼◼◻◻◻ GES
- ◼◻◻◻◻ GStreamer
This section is here to give you a minimal set/starting point if you don't know what to work on or are looking for inspiration. Some items come from the PiTiVi Love page, the bug tracker, the roadmap or from our overall vision for the project. You are welcome to ask around and bring your own ideas. Hurry up, deadlines for applying are approaching fast!
General debugging and bug fixing in GES and Pitivi
The title says it all. To apply for this, you should be able to demonstrate that you are reasonably familiar with Pitivi's (and GES's) current state, its strengths and weaknesses. You must be able to provide a clear plan that lists the things you want to fix and explains (roughly) of how you would investigate/tackle those issues, what tools you might use, etc.
◼◼◼◼◻ Pitivi ◼◼◼◼◼ GES ◼◼◼◻◻ GStreamer
Keyframe animation backend and interface for properties
It is currently not possible to change a clip/effect/title's properties over time. Your mission would be:
Implement the notion of properties keyframes in GES. This is mostly a matter of making proper use of GstInterpolationControlSource in GES.DONE
- Finish the implementation of an intuitive and beautiful user interface for it in PiTiVi (bug 619654 and bug 675035)
As you can see, the remaining part is the UI, which is not enough alone to constitute a GSoC project - you can consider combining this task with some other ideas to make a more challenging GSoC project proposal.
Beyond the keyframes UI for effect properties, you should also provide a user interface to control the volume of audio clips using keyframe curves directly in the timeline canvas (like in previous versions of PiTiVi... but better!).
◼◼◼◼◼ Pitivi ◼◼◻◻◻ GES ◻◻◻◻◻ GStreamer
This will require some work in GES and should leverage the new animation capabilities of our Clutter timeline canvas.
From the backend perspective, the idea is to create a new "GESTimelineClip", subclass of GESClip that would contain GESTrackTrackElement-s (as GESTrackElement-s), this class would be a subclass of GESTrackElement. This new GESTrackTrackElement class would contain a GESTrack inside its gnlobject (actually a GnlComposition inside its GnlObject). The end result is that we have a GESTimeline inside a GESClip.
To get an overall idea of what this means from a UI perspective, see also the grouping and nesting brainstorming page.
◼◼◼◼◼ Pitivi ◼◼◻◻◻ GES ◻◻◻◻◻ GStreamer
Multi-cam editing workflow
This will depend on the nested timelines to provide a special case for multicam clip edits in Pitivi's UI.
◼◼◼◼◼ Pitivi ◼◼◻◻◻ GES ◼◻◻◻◻ GStreamer
Motion ramping / time stretching
The ability to change the speed of clips over time is a very useful feature to add dramatic or comedic effects to cinematic productions. Some initial experimental work has been done with this, but only for a fixed clip speed. Your mission would be complete the work on clip speed, and implement the ability to use a variable speed inside a clip (what is commonly called "motion ramping"). See also bug 593828. To summarize, your mission is:
- Research and stabilize the work that was started on "fixed speed" clip speed changes (ask stormer, thiblahute and others on IRC!). Also, check the status of the proesmans OpenCV optical flow gstreamer plugin (last time we checked, the code from the 2011 GSoC was here)
- Implement a backend to allow the speed of a clip to vary over time. This might require work in GES or gstreamer.
- Implement the user interface for simple motion ramping in the timeline
- Secondary objective/bonus points: implement an alternative user interface for complex motion ramping
◼◼◼◼◼ Pitivi ◼◼◻◻◻ GES ◼◼◼◼◼ GStreamer
Reimplement audio mixing and video compositing
Compositing (being able to "mix" video layers on top of each other or to apply effects requiring transparency, for example) and audio mixing were implemented in versions 0.13.x to 0.15.x directly in Pitivi, in software. Your mission would be to reimplement that properly in GES instead for better flexibility and performance. This task is important because, without it, Pitivi 0.16 will not have compositing as previous versions used to and will not be able to have multiple sounds playing at the same time.
- Primary objective: implement video compositing and finish audio mixing in GES. See the "Video compositing and audio mixing" section of the current GES design spec.
- Secondary objective: Optimize the video mixer. Implement a GstMeta so that the mixing can happen in the sink (usually cluttersink)
- Third objective: integrate this in Pitivi (make use of cluttersink)
◼◻◻◻◻ Pitivi ◼◼◼◼◼ GES ◼◼◼◼◻ GStreamer
Finish the implementation of Complex Layers
The current development version now has a user interface for managing layers in the timeline (see bug 632319 for some details about what kind of functionalities this allows).
To help you imagine what we're talking about, here is a rough mockup we did at GUADEC 2011:
...and a screenshot of the current user interface/layers UI implementation of that mockup:
- Primary objective: Implement the missing properties (for compositing, audio mixing, etc.) in GES. For those properties, implement metadata in the project file formatters. Connect all of this with the relevant widgets in Pitivi's layers management UI.
- Secondary objective: allow applying effects to layers (not just clips)
◼◼◻◻◻ Pitivi ◼◼◼◼◼ GES ◻◻◻◻◻ GStreamer
Proxy editing is the ability to swap clips by a "proxy" version that is more suited for editing, and then using the original, full-quality clip to do the render. This is useful when working with input formats that are not efficient/fast for live editing or when dealing with high definition/computationally expensive footage for which the computer is not powerful-enough to handle realtime playback.
This should be integrated into pitivi's set of features so that it works transparently and reliably for users that want to use this feature.
- Implement the proxy clip handling in GES according to the design spec
- Implement batch transcoding of clips into low resolution, easily seekable/editable formats (such as OGG Theora)
- Implement automatic management of the "proxy" and "original" URIs of the clip in the project
- Automatically/dynamically use the "original" version when rendering (unless the user chose to render in "draft" mode)
- Build a user interface in PiTiVi for the user to activate the feature
- Ensure it is all rock-solid/write unit tests
- Ensure that even if the user moves the proxy files or the original files, pitivi can still locate them (this is already implemented, but needs to be extended for proxy files)
See also bug 609136.
◼◼◼◼◼ Pitivi ◼◼◼◼◻ GES ◻◻◻◻◻ GStreamer
Reimplement waveforms as a GStreamer element
This is a challenge for heroes, pure GStreamer work in GObject C.
See also http://gstreamer.freedesktop.org/wiki/AudioPeaksElement for bemasc's thoughts/analysis in which he concludes that what would be needed is something like the gst "level" element, but producing buffers (of hundreds or thousands of level measurements) instead of signals (one for each measurement). He jokingly warns: "don't read that page too closely; it's a bit like the rambling journal of a descent into madness."
(details missing here, but ask nekohayo and others if you're interested)
Although Pitivi would not be the only application to benefit from this, you'd be expected to integrate the use of this feature into Pitivi. You know, just to show your total supremacy and mastery of the stack.
◼◼◼◼◼ Pitivi ◻◻◻◻◻ GES ◼◼◼◻◻ GStreamer
A library to interface with Blender
...and the corresponding UI to use it in PiTiVi. OpenShot has a feature that calls Blender to do 3D animated titles, special effects (particles, lighting, animated world maps, etc.).
- Currently, OpenShot achieves this simply by forking out a process that executes Blender with a python script and .blend file as arguments, parses the output (with regexes) from the terminal and imports the result.
- The lead OpenShot developer has expressed interest in making this a separate library so that other applications can benefit from it, but needs help to do it: someone needs to step up, figure out how to do it "properly" with a library, and do it. He would then be happy to help with the effort.
◼◼◼◼◼ Pitivi ◼◼◼◼◼ GES ◻◻◻◻◻ GStreamer ◼◼◼◼◼ Blender ⚠ — requires a joint mentorship with the Blender project
Who we are looking for
- Creative and motivated developers interested in multimedia and video editing
- Highly communicative people. Stuck on a problem? We need to know. Achieved a milestone or solved a really nasty problem? The entire world needs to know. (And if you're too busy hacking to publicly blog about your progress, nekohayo can help you with that).
- Candidates interested in making PiTiVi known as the video editor with the best user interface and legendary reliability.
- Candidates willing to become part of our community
- Required: interacting with us regularly on IRC. It is fun to hang around with other contributors, makes your project goals easier to accomplish through better mentorship and shared insights, and shows more willingness to get involved in our community in the long term. Email is not sufficient.
- Knowledge of Git, GStreamer, Python, Cairo and related technologies is a plus
- Knowledge of the C programming language is a plus (for projects that require changes in GES)
- Familiarity with Test-Driven Development is a plus
- GSoC projects are on a "full-time" basis, not "part-time". What this means is that you should not apply if you have some strange schedule where, for example, you have school exams for many weeks between early May and late August. If you have school exams/obligations during the summer, you need to mention them/account for them in your schedule.
What we offer
- A fantastic learning opportunity to play with technologies such as GStreamer, GTK+, Cairo, Python, etc.
- A tight-knit community that will offer you guidance and feedback throughout your project
- In addition to your "official" mentor, you may get help from other mentors and members of the project.
- For all UI-related tasks, you will be able to receive additional help and mentorship (in terms of design, guidance and testing) from nekohayo.
- Tangible and fun projects with the potential to improve the lives of thousands of users
- The opportunity to meet us at GUADEC where you can have fun and present your accomplishments to others!
- And dozens of other reasons for contributing
How to apply and get started
As part of the application process, we require patches/some small contributions to demonstrate that you have sufficient technical skills, motivation, and have some familiarity with the application and its source code. This also ensures that you get to know members of the community and have sufficient time and information to properly plan your project.
You don't have to be a veteran hacker/contributor, but experience tells us that it is important that you prove to us — and to yourself — that you know what you're getting into. See also the GNOME outreach programme's section on "small contributions" to learn more about this philosophy.
Therefore, you should proceed like this:
- Discuss your ideas with us on IRC.
- Get your development environment set-up and working. Explore the application, what works well and what doesn't, etc. See also Building with GES.
- Make a small contribution (or more!) - see also PiTiVi Love and the contributing page.
- Request an account on this wiki (see the lockdown policy) and edit your own user page (optional but highly recommended; the quality of your application will be much better as a result!). For example, if your wiki username is "Kiddo", you can go to User:Kiddo and edit the contents. This page should contain:
- A section where you tell us a little bit about yourself. This is useful for your public identity as a member of our community. You don't need to be as crazy as "Kiddo" regarding how much information you put in there, but try to convince us that you're the right person for the task! Don't forget to provide some contact information (at least your usual IRC nickname, your blog if you have one, etc.).
- A section for your GSoC project proposal(s). Try to demonstrate the research you have done for the project(s) you have chosen to apply for, tell us about how you plan to do your implementation, try to give us a realistic roadmap/schedule estimate, etc. Some examples of questions to guide you can be found here and here (you will have to use those official templates to apply to GNOME and GStreamer, but don't let that limit your creativity for your pitivi wiki page here).
- Add yourself to the people :)
- Announce your final (or semi-final) proposal onto the PiTiVi mailing list, pointing to your wiki page (you may get some more feedback!). Indeed, PiTiVi can work under the umbrella of both GNOME and GStreamer, but GNOME has no general mailing list for discussing GSoC ideas, and GStreamer's development mailing list is quite busy (and your post may be buried among other topics).
- Apply to Google's Summer of Code Melange website under both the GNOME and GStreamer mentoring organizations. Mentoring organizations can easily exchange applications as long as they communicate.