Cinelerra — the next step

reworking or rewriting Cinelerra?

a GUI draft

Some of the links above are snapshots of files in the GIT tree. Note it's a young project in the design draft state and doesnt contain any finished or otherwise usable code.

by Ichthyostega, January 2008. It started last Summer with discussions of some Cinelerra-CV coders and community members about the state of the current codebase, problems we encountered while trying to extend, fix and use it for editing work in larger projects. These discussions were techique centric. We know what users request and need for using Cinelerra, e.g. in small News and TV stations or indie film projects. Video editing for Linux in general and Cinelerra especially are almost there — but only almost.

At that time, I wrote a roadmap for reworking some parts of the existing Cinelerra codebase, deep down in the core. Christian Thaeter set up an initial Manifesto and supporting infrastructure. We invited Adam and the other Cinelerra-CV coders to participate, but we didn't yet announce it on the Mailinglist and we agreed to avoid "UI discussions" for now. Hence the preliminary name "Cinelerra-3".

I want to take the opportunity to thank Adam and the other Cinelerra coders for bringing us to the point where we are now. This new project is very much rooted in Cinelerra, most of us use Cinelerra frequently for their own editing work, we continue to use the terms coined by Cinelerra and we still judge its technological approach being basically right.

In the following months we got a much more clear picture by analyzing and drafting and coding into the details. Meanwhile, we have built up some infrastructure like: source tree, includes, build system(s), automatic test suite, API doc and wiki based design documentation.

Christian focused on the data backend, including data access, support library, plugin system, organizing video and audio frame handling based on existing external libraries and planning a frame cache system that will go beyond what Cinelerra provides today. This part will be implemented in plain-old-C style.
I for my part focused on the middle layer, consisting of the mechanics supporting the edit operations, organizing a collection of "media objects" in the EDL(s) and building a render node graph, which can be run by the backend to cary out the rendering. This part is heavily object oriented and written in C++
We are determined to make all extending parts beyond the core very modular, have various plugin extendable subsystems, adapt existing plugin collections, being entirely scriptable and include a rule based aproach for configuration within the session/EDL and connecting "media objects".

Have fun
Hermann