Lumiera
The new emerging NLE for GNU/Linux

Lumiera aspires to be a professional tool for video editing on GNU/Linux systems. The vision of the development team defines a modern design for the core of a Non-Linear Editing software. A key aspect of Lumiera is the strong separation between the user interface and the processing core. We are developing Lumiera with a general purpose GTK UI — which is loaded as an optional component, so that the core can also be invoked from scripts to use the editing and processing capabilities of the engine. This becomes possible by an ongoing effort to decrease coupling. Each major component in the application strives to be open to extensions, but closed against external modification. The presentation, the model and the “performing” of the model are separate and self-contained parts of the application. Lumiera as a processing core will be able to perform any conceivable task on video and audio, maybe even tasks entirely unrelated to video editing.

Workflow

The word “workflow” is used to name the way tasks can be achieved in an application. Any operation in Lumiera must be possible in the most suitable and stringent fashion. The workflow is closely related to how flexible the GUI is but is also the concern of deeper and more technical parts of the application.

Overview

Lumiera is built from numerous subsystems. This overview will provide a general description of the major components from the highest to the lowest level. Lumiera is composed of three main areas with a few additional extra components. We discuss these areas below.

Stage: Graphical User Interface

User interfaces are implemented as plug-ins. As a consequence, it is possible to interface with Lumiera through scripts. It is also possible to create specialised GUIs. The interface is the component that is closest to the user. It provides purely visual interaction with the user. Within this work environment, the user manipulates, organizes, loads, configures all sorts of data, especially MObjects (media objects) and Assets. These elements are contained within a structure called the Session.
GUI/Stage-Layer design documents
GUI technical documentation

Steam: the Transformation Layer

The “Steam Layer” covers several closely related aspects. When the user works with the GUI, all the clips, effects and other visually presented components are actually stored within the Session model (“high-level model”). Any editing operation initiated by the user is actually executed in the context of the session. Next, after each change, a component known as the Builder assembles the contents of this session model to transform them into a network of nodes, which can be efficiently performed for rendering. Often, we refer to this node structure as the “low-level model”. On rendering or playback, the Steam-layer is responsible for accessing this low-level node structure to generate individual frame render jobs, ready to be handed over to the Vault, which finally initiates the actual rendering calculations.
→ more about the Model
→ design of the Engine subsystem

Vault: Low-Level Services

The Vault Layer attaches to the low-level model and the render jobs generated by the Steam Layer. It actually conducts the rendering operations and makes heavy use of the Input/Output System for accessing media content and sending generated data to the screen or to external output.
Lumiera Vault design level documents
technical documentation

Extra Components

The Vessel

A structure that is anchored below all layers, yet contains everything, conceptually. Definitions for building common interfaces are located here, as is the mechanism for initialisation and shutdown of the application, the loading of bootstrap configuration and optional components. It encloses and coordinates all parts to work together as a coherent whole. This → Application framework is complemented by a Support-Lbrary with commonly used components, algorithms and data structures.

Extensions

Lumiera uses proven and field-tested implementations for the actual media processing, which are available as FLOSS or open-source libraries. To avoid extensive external dependencies on the main application however, such libraries need to be loaded through adaptor plug-ins. Furthermore, the application will be configurable and it is conceivable that external extensions will be created. Designing and building a future-proof framework for configuration and extension is an important medium-term goal for further development.