Cinelerra-3 Project Proposal

just don’t rely solely on common sense and handwork,
bring in proven tools and methods.

some facilities are better to setup beforehand.

the runtime behaviour of the current Cinelerra app is quite frightening. It creates lots and lots of threads, uses a locking scheme obviousely broken, and it segfaults on a regular base. We need to stop this. Cinelerra is inteded to be used for professional work. With respect to this pretension, the current state is plain ridiculous.

Twofold.

Nothing dramatic. The same code base.

need some abstraction for the “media objects”. This should enable us to pass and manipulate those objects in an uniform manner, without being tied to the specific properties of the given object. We can (and should) borrow the basic ideas from existing libraies. We should decide, if we can even use those libraries to do some of the work for us. Next, we have to identify “corresponding features” in the existing code base. I’m quite content, that we will find it to be quite sensible in this respect and that all we have to do is some aligning and reordering of methods. (e.g. in the VFrame object)

just being able to access media streams in a uniform manner and being able to write the backend interface, which will encompass all future media stream access. Add this code and maybe alredy the interface classes to the code base, but don’t use it.

the rendering pipeline is alredy quite self contained and has rather well defined borders, so it is a good candidate to get the first grip at. Moreover, it is the reality test par excelance: if our ideas, design principles, foundations and abstractions aren’t sound, then performance and stability will be worse then at current.
Quality is measurable here.

The rendering pipeline consists of processing nodes and works in pull processing mode. We won’t change this.

the current implementation…

Introduce a new controller component, the RenderManager. Rewrite existing code “out there” to interface directly to it. This solves (a).

All of the rendering, playback and EDL manipulation code is working as before, with the same usage pattern (including multithreading). In spite of this, the core rendering engine code (and hopefully the processing code in the plugins) is drastically simplified, because we have factured out several crosscutting concerns, centralized a good bunch of decision logic, ruled out most of the switch-case-blocks together with the macro stuff caused by them, as we can now utilize our improved data abstractions developed in Milestone-2. If we are clever, we will see performance gains due to new memory management possibilities (but we shouldn’t expect too much here).

doing some rather simple and isolated improvements, preparing Milestone-5, getting user feedback for Milestone-3

_{to be written…}

Storing and loading is scattered all over the code, and tangled with the undo/redo and copy/paste functionalities.

_{to be written…}

New Session storage system in place, more possibilities to do format conversions, besides that, everything should work as before.

At some point, we need to do the big step and introduce common container classes and the standard library. Moreover, this core object network needs a slightly augmented structure and some improved abstractions, in order to be able to implement all those feature requests now lurking in our famous bug tracker since years. Also, if we want to implement a fully event-centric GUI at some point in the future (Milestone-7), we need centralized service oriented access points to all of this object manipulation, i.e. a real client-server aproach.

All of the edit session content and state is contained in a structure of connected objects, most of this connections beeing of collection-type (implemented by double linked lists). A Session is a collection of tracks, which in turn contain a collection of edits, pluginsets, collections of automation-nodes and keyframes of various types. At the moment, this structure is accessed directly from both sides (GUI and Render Engine). Further, the cleaned-up structure of the Render Engine (Milestone-3) puts a new demand on this object manipulation subsystem: it needs to do the building and connection of the render pipeline object graph. Quite in line with this are some of the long standing feature requests of the users: the ability to link media objects (clips, sound and effects) and move them in combination, the ability to do individual keying of plugin parameters. Because the performance pressure is rather low in this region of the system, we may well think of using advanced programming techniques to solve this problems. At the moment, I could imagine to embed some Prolog engine here, or something of this sort. At least, we should prepare for the ability to do so in the future. Such things are absolutely impossible as long as all of the processing is done by directly passing along pointers to linked list nodes, or, worse, references to such pointers, it’s just not the right abstraction level. Rather, there should be augmented Asset-Objects which could encompass some layout and association rules. Like: “place this plugin below that clip”, or “place this keyframe sequence relative to that plugin”. We really don’t need a full-blown constraint solver here, but some sort of rule-driven aproach will make this things more simple and manageable.

currently, most operations are done by directly modifying inner object properties from outwart in a completely unstructured manner. It’s an almost intangible, monolithic labyrinth of dependencies. So we need methods of breaking out parts and create new separation layers. Moreover, at the moment there is overly heavy multithreading, and we want partially to get rid of this in the GUI layer.

Create a new CommandDispatcher-Component and (temporarily) introduce a layer of proxy-objects above this. The proxy objects can be accessed in a similar manner from the existing code (mainly in the GUI layer) to the way the real objects are now manipulated directly by the GUI. Of course we have to replace direct manipulation of object fileds by getter/setter calls. The proxy objects in turn access the new interface on the CommandDispatcher, which reacts by advising the new (or reworked) media object manipulation subsystem to carry out the desired action. The net effect is to replace external manipulation by letting the EDL media objects themselves provide the desired service, maybe even asynchronousely.

Not sure what the goals should be.
Possibly this Milestone will be about replacing a good part of the core app. But it is also possible to think of it rather as an Adaptation Layer for integrating the new Backend and Render Engine, while the “editing part” of the App stays unchanged functionallity-wise.

At this point, we can start to take profit from all this internal reworkings and also to realize the potential of the augmented structures.

The most important thing to do here is an improved Cache Manager and a more intelligent re-use of (background)rendered frames. If we just implement what’s possible on top of Cinelerra’s clear and straightforward structure, we can get way ahead of a good bunch of our competitors: If we manage to rerender really just the recently changed parts of the session and nothing more, a simple aging aproach to the cache organization will yield us pre-existing frames ready for playback most of the time. I for my part assess this as beeing far more important then augmenting hardware acceleration (note: for the conventional video editing cinelerra is taylored at. 3D animations or virtual reality is quite a different thing)

after having solved the adaptation problem to the existing code in the data backend and in the GUI layer, I don’t see any further difficulties. Moreover, there is no project dependencies pressure, i.e. we can implement what is feasible here and make our users happy.

Runs like greased lighning, rock stable 😜

gain better usability, be cool…

Starting form the CommandDispatcher introduced in Milestone-5, rebuild the current GUI using one of the existing GUI toolkit sets. Openes the ability to have collapsable tracks with sub-tracks for the automation, for displaying keyframes and curves for every imaginable parameter, for letting the user directly edit connections of the data processing network, for gaining more screen real estate and improved usability by tabbed property editing boxes, user-defineable key bindings, dockable sub-windows, vector-graphic-driven rendering of widgetes, etc., etc., etc. …

an application, that’s not only advanced, clean and quality oriented in its inner workings, but conveyes this properties in the user experience (do you need more marketing fluff?)