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.

Contents 1 What's your style? 2 Some ideas 2.1 General debugging and bug fixing in GES and Pitivi 2.2 Keyframe animation backend and interface for properties 2.3 Nested timelines 2.3.1 Multi-cam editing workflow 2.4 Motion ramping / time stretching 2.5 Reimplement audio mixing and video compositing 2.5.1 Finish the implementation of Complex Layers 2.6 Proxy editing 2.7 Reimplement waveforms as a GStreamer element 2.8 A library to interface with Blender 3 Who we are looking for 4 What we offer 5 How to apply and get started 6 Past summers of code

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

Some ideas

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:

1. Implement the notion of properties keyframes in GES. This is mostly a matter of making proper use of GstInterpolationControlSource in GES. DONE
2. 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.

It was suggested that the interface could look like this (but it's not the only way: the current implementation puts the keyframes directly on the clips in the timeline...):

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

Nested timelines

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:

1. 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)
2. Implement a backend to allow the speed of a clip to vary over time. This might require work in GES or gstreamer.
3. Implement the user interface for simple motion ramping in the timeline
4. 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

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.

Your mission:

1. Implement the proxy clip handling in GES according to the design spec
   1. Implement batch transcoding of clips into low resolution, easily seekable/editable formats (such as OGG Theora)
   2. Implement automatic management of the "proxy" and "original" URIs of the clip in the project
   3. Automatically/dynamically use the "original" version when rendering (unless the user chose to render in "draft" mode)
2. Build a user interface in PiTiVi for the user to activate the feature
3. Ensure it is all rock-solid/write unit tests
4. 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.

This has been partially done during GSoC 2012. The current state of it is described here and the code can be see there.

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

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:

1. Discuss your ideas with us on IRC.
2. Get your development environment set-up and working. Explore the application, what works well and what doesn't, etc. See also Building with GES.
3. Make a small contribution (or more!) - see also PiTiVi Love and the contributing page.
4. 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).
5. Add yourself to the people :)
6. 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).
7. 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.

Past summers of code

• SoC 2007
• SoC 2008
• SoC 2010
• SoC 2011
• SoC 2012