Lumiera
The new emerging NLE for GNU/Linux

In Brief

This year has seen an increase in developer activity in Lumiera. This can be attributed to a strategic decision made by the developers in recent years to continue devoting time and energy to the project. An additional provision has been made to invest significantly more developer time in the project. The project should also benefit from a slight shift in focus towards integrating component parts together that were developed over the past few years which will enable developers to examine and put to the test many aspects of the Lumiera design itself as originally conceived by the developers at the project’s launch.

While some fine-tuning to the Lumiera design was required, the overall design (as had been anticipated) proved to perform as originally expected. The first round of integration steps is currently drawing to a close. While work on the integration of the Render Engine will provide valuable information to developers, it will also provide a glimpse into progress for potential Lumiera users.

We have been asked over the previous years — and indeed the question has been posed among ourselves — as to why continue with Lumiera? We discuss the question below.

As was customary in all of the previous years, some of the developers met in person and attended the annual FrOSCon conference in August.

In Detail

Right from its very inception, the Lumiera project strived towards professional and high-quality work. Here, the term “professional” does not necessarily imply that this work is done in a commercial setting or industrial context. We do, however, wish to convey an attitude or frame of mind in our approach we make to our work. Professionalism implies pursuing work with sincerity and subjecting oneself to engaging in its essence and not looking towards rewards or any other peripheral aspect associated with it.

This, our work ethics, has direct implications in the field of film editing as it implies the need or even the necessity to support high resolution data formats and extended colour spaces. More importantly, the software must be sufficiently versatile as to be able to adopt itself to new technological developments and trends. Lumiera has been conceived as a tool for craftspeople, delivering both reliability in conjunction with flexibility to deliver a film edit. The user must have the freedom to glide seamlessly from raw material exploration, then to the phases of building a rough edit, next on to working on the narration, subsequently followed by compositing and finally to finish up with fine tuning and grading. High-quality processing combined with freedom of choice comes at an expense: increased complexity. One of the golden features of the Lumiera architectural design is its ability to cope with this complexity while still retaining precision (→ more here).

Anyone familiar with the process of film creation is well acquainted with the stages and the associated requirements and tasks needed to perform them. Any one of these tasks taken in isolation can be reasonably mastered by modern day software and hardware. The real challenge is surely the ability to integrate these various stages in a seamless manner so as to afford the user maximum leeway and flexibility in combining the building blocks. The formidable task is to build such an application as there is no blueprint available to guide anyone in how to achieve this. This was the price paid by the Lumiera project. We had to trudge through a year-long phase of research and prototyping accompanied with deeper analysis. The nature of this work can be more appropriately described as an expedition into partially uncharted territory. Results can not be derived from first principles alone, many details need to be examined before being able to establish a vague picture of possibly how things could fit together.

With the recent achievements of connecting the GUI to a flexible and open ended model description in the Session, this work of mapping out the design space is gradually nearing an end. A general style and common traits of the solutions required by Lumiera has emerged:

  • the application is composed of self-contained parts, each exhibiting low coupling among one another

  • interaction among the self-contained parts is by exchanging messages, asynchronously

  • these messages transmit a symbolic representation of structures and metadata

  • this symbolic representation allows us to represent domain knowledge using declarative rules which contains information on the best way to handle and process data

The Vertical Slice

Lumiera development to-date was mainly concerned with components: designing components, building components and delivering components to provide some definite functionality. With the successful connection between GUI and Session, we’ve started using these components as our basic building blocks to provide some new functionality. The scope of this new functionality now expands down into the very core of the Render Engine.

»Playback Vertical Slice«

Lumiera Architecture 

Graphical depiction of the
vertical slice and the various
components involved.

The Lumiera developer news report from last year reported extensively on our intention to implement a vertical slice. There, we also described our reasons for doing this, see report, and have a tracking ticket.

Once finished, this vertical slice will allow a user to start the display of (pre-defined) video content by pushing a button in the Lumiera GUI. The implementation has made much progress over the course of the last months. Several existing parts of the player were successfully integrated. Some components were not yet available so we mocked these. Other more crucial parts playing a vital role in the workings of Lumiera were implemented from the ground up to allow developers to scrutinise its performance in the vertical slice, but also in combination with components under development. One such component was the Scheduler.

Time bound delivery of media data is an important aspect of editing and playback — yet, other concerns are of similar importance: the ability to make optimum use of scarce resources and to complete extended processing in acceptable time, while retaining some overall responsiveness of the system. And, especially for the final render, it is tantamount to produce reproducibly correct results without any glitches, spending whatever time it takes to complete the work. So the Lumiera Render Engine is bound by several, partially conflicting goals and sometimes faces a situation where available resources are insufficient.

Scheduling is one well established solution to handle such a situation smoothly. Work is broken down into tiny jobs. Such jobs can be classified according to various criteria and combined in order with respect to priority. Limited resources can be used where it matters most. Moreover, placing a scheduling mechanism into the centre of the engine opens a way to flexibly adapt to future demands. It is possible to assign some tasks to dedicated hardware, or to have them dispatched over the net into a render cluster, all integrated seamlessly with the rest of the application.

The bulk of the work to implement the scheduler has been completed, see details. The render nodes (from the low-level model) are not yet connected, but first measurements with mocked render jobs indicated that the new implementation satisfies necessary time constraints: time observation.

Why Continue?

Well, most obviously, we enjoy doing it. The many challenges encountered by working on Lumiera: surmounting interminable complexity while retaining precision and engaging uncharted territory while retaining our professional mind-set are some of the ingredients which contribute to our joy in working on Lumiera. But, our personal gratification does not necessarily justify devoting a considerable amount of time to pursue such a costly endeavour---well, at least not for us, the current developers.

We believe that we have unique ideas and that there is no Open Source project currently available providing the scope, functionality and vision that embraces the reaches Lumiera perpetuates to provide. We are increasingly being justified by the slowly emerging features from new code that fortifies these assumptions.

Of personal interest to the Lumiera developers is making a contribution to the Open Source Community, a community that has given us, the Lumiera developers, so much over the years and the ability to feed back to the community is a personal gain. The Lumiera project has gained so much from the community, indeed its roots may be traced back to that very community, and continues to do so. And this is a commitment which we, the developers, will pursue not only for now, but also to ensure that the project remains in the Open Source for long to come.

We must finally mention the developer satisfaction in operating in such an environment and not in a commercial cage.