VideoEdit is related to my Google Summer of Code 2008 application,Roberto Faga 28 March 2008
- Also, this application is intended to integrate/work together with the VideoEditing and Record projects.
The main idea of this activity is to provide simple operations with videos. It is not intended to be complex, the easier the better. This should let a young child cut and paste parts of a video, record his voice over a video, put text as a subtitle or as a note and many other annotation operations. So the idea is not to only provide the simple operations which every video editor have - like copy, cut, add effects (not intended to the first version) - but to provide annotation (or comments). After the first release, this application can so start to explore collaboration - children seeing annotations by other children and annotating over it.
The edit/annotate operations can be done with basic operations - like arranging different sounds and videos into a final video and annotating in a video - or with more advanced operations - like adding possible effects and more precisely operations. The activity can have three possible approaches:
- Be integrated with Record activity, in some new tabs, exactly like Projects/VideoEditing idea. It is good to the annotations and to a quick video production, but it can turns Record activity too heavy/complex - maybe ordering nicely all operations can turn good to use integrated.
- Be a separated activity, with no relation with any other activity. It turns more easier to use and maintain the code, but opening a new activity for video annotating doesn't sounds so good.
- Mix both ideas, so a separated activity for most complex operations and mixed operations into Record activity for simple operations, like annotations and simple edit.
I personally prefer the first approach, as is easier to use and integrates with another big activity, Record. Also, this activity can work in a tab mode, limited only to the tab (not depending of any other place of Record activity) so it can be incorporated into any other activity just importing the VideoEdit toolbar and starting it, something like this. With this method, the edit operations can be added , e.g., in a video player, allowing users to edit/annotate even videos on the Internet.
 Designed Operations
Here it is listed some operations that VideoEdit could have (feel free to add anything desired):
- Cut/Copy/Paste: these basic operations are expected to have in the first version. They are essential to any video editing.
- Audio mix/extract/replace: working with audio extract, mix and replace to let user to change the audio of a video, mix with another and record with microphone a new audio.
- Convert videos: if this activity has a nice library with many codecs, an operation to simple convert videos op will be nice. Storing a big mpeg video in some other video format lesser than mpeg.
- Add texts,parallel videos and pictures: This part starts with a complex type of operation, annotating texts and merging videos and pictures. When this operation completes, a small animation maker is done, as user can do some presentations and using the power of technologies like SMIL.
Project should be done with Python and pygtk/sugar elements as they are needed. Integrating with Record activity is a great feature to do, but this depends of Record coders to help me on this (and permit me). The activity can be an activity separated, totally integrated with Record activity or using both methods. Developing integrated with Record can be nice if VideoEdit offers only a toolbar and a widget that can be used in Record activity but in any other activity, like a video player or any other media tool. As library to use, Projects/VideoEditing is using a good plugin for gstreamer: GNonLin. It's the same plugin used by PiTiVi video editor, looks to have easy edit operations, but it lacks more documentation. Even without complete doc, it looks a good solution as Sugar already uses gstreamer. Also, Robert Ochshorn already proposed to help me with this (and we work together in a single activity).
I divided the activity in the following parts (got inspirited by VideoEditing again):
- Core : Every program has a core. The core here is supposed to allow editing videos, mixing audio/texts/images and so on by inputing in python functions videos, audio and needed/desired parameters. The idea here is to have a lib using gnonlin/gstreamer to provide the operations and let any other program use later. Anyway the idea isn't to isolate the core from the program, but build its base. For this module, checking other gnonlin programs (PiTiVi e.g.) is essential, as working together too.
- Arrange : Select inputs to create a video - User can select different videos and audios to mix them into an output video / some other format. This tool must be easy and fast, to allow only combinations of media already stored in XO. Ochshorn made a nice screen design of this tool at Projects/VideoEditing.
- Edit : As Ochshorn written too, a tab/tool to allow users advanced edit operations. Some of them can be cut/copy/paste videos and static images and - not intended to be done into this Summer of Code - insert more advanced resources like animations, videos into videos, some interactive resources, etc. Also, this part is intended to provide more precisely operations, like video syncing and putting audio at a desired time.
- Annotate : This new feature should let user to annotate in a viewing / making video. Simple annotations like tagging some specific time of a video (this requires to use some format like SMIL), recording audio over a part of the video, inserting subtitles and annotating in a specific frame - video pauses and user can use a Paint activity over it. Later the video has the annotation, user can export with the annotation or export in some interactive format that allows video viewer to select if he wants to see the annotation.
Here I'm showing a possible schedule to the project. It's something that I can feel I can complete alone, but working together with VideoEditing should bring more/better results. I'm proposing to work until the end of August, completing 3 months and 1 week, because I'll have free time in these three months. Before and after them I have too, but not many as in they. Also, I'll have full-time free on July.
- Until the Summer of code start: study gstreamer, gnonlin, Record activity and discuss with community what can be done. Draw some interfaces in paper, draw some flowcharts which can help and make some uses cases.
- From end of May to end of June: code basic Core to allow simple video operations. Start drawing the screens officially.
- From start to end of July: Code small operations to allow a simple working version of VideoEdit, with at least Arrange working well.
- From start to end of August: Implement Annotate and Edit with basic operations, let Arrange work completely.
- From September to ...: Code what is missing.
I can't write the dates of milestones exactly as it depends of Robert and Record authors too. Also I want to testing the activity in parallel, not releasing only the final version.
Here are some possible difficulties that this project can have and how do I pretend to resolve them:
- Memory to store editable version - XO has a short memory. So, how could we store the editable version of video? One possible solution is to use SMIL and convert all media used in the OUTPUT wish-format (like only ogg/theora+vorbis), and this also support annotation. Also, storing old videos in the server could be done too.
- Plugins to work with videos - outputing only ogg/Theora is nice to the application, but opening only this type of video can restrict activity a lot. For an example, user can get a video in mpeg1/2/4, xvid, flv formats. Without this support can be frustrating to a child to edit videos - even play them, as until this moment there isn't a specific video player activity. gstreamer installed in XO can open how many video formats? I think this isn't a problem from this activity only, but from any other media-related activity, as we have problems with licenses and patents of each video/audio type depending to where XO will be delivered. To solve this problem, I just pretend to work with what XO supports - and perhaps suggesting a server video-converter based tool if memory to store plugins is a problem.