Benny
8790e2af46
TODO: Backend, needs just a little more, not much, e.g.:
Area where low-level memory, hardware i/o, etc occur => here
is where real gain in efficiency through modern algorithms can occur,
thus, achieving another goal of Lumiera: efficient & runs on all kinds
of hardware!
108 lines
4.8 KiB
Text
108 lines
4.8 KiB
Text
Lumiera Design Documents
|
|
========================
|
|
|
|
// Menu : prepend child design/backend
|
|
// Menu : prepend child engine
|
|
// Menu : prepend child model
|
|
// Menu : prepend child design/gui
|
|
// Menu : prepend child architecture
|
|
|
|
// Menu : append child plugins
|
|
// Menu : append child workflow
|
|
|
|
The goal of Lumiera is to provide 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. One of the key aspect of Lumiera
|
|
is the strong separation between the user interface and the processing core.
|
|
Lumiera as a software will come along with a GTK GUI but that does not make this
|
|
exclusive, any other GUI could be written as well as scripts to drive the core.
|
|
This is made 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 do anything possibly conceivable, therefore it
|
|
may be used to do any task on video (and audio?), even 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
|
|
--------
|
|
|
|
The internal structure of Lumiera is divided into numerous subsystems. This
|
|
overview will provide a general description of the major areas that make up
|
|
Lumiera from the highest down to the lowest level. Lumiera can be considered to
|
|
be composed of three main areas with an additional extra components. We discuss
|
|
theses areas below.
|
|
|
|
Graphical User Interface
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
User interfaces are basically implemented as a plugin. As a consequence, it is
|
|
possible to interface with Lumiera through scripts. It is also possible to create
|
|
specialised GUIs. The interface is the closest component to the user. It is
|
|
a purely visual interaction with the user. There 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. +
|
|
-> link:gui/index.html[GUI design documents]
|
|
|
|
|
|
The Processing Layer
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The processing layer (``Proc-layer'' or ``proc'') covers several closely related aspects.
|
|
While the user works with the GUI, all the clips, effects and other components presented
|
|
there are actually stored within the _Session model_ (``high-level model''). Any editing
|
|
operations initiated by the user are actually performed here. Next, after each change,
|
|
a component known as _the Builder_ assembles the contents of this model and transforms
|
|
them to form a network of nodes, which can be _performed_ efficiently for rendering.
|
|
Often, we refer to this node structure as the ``low-level model''. On rendering or
|
|
playback, the Proc-layer is responsible for accessing this node structure to
|
|
generate individual _frame render jobs,_ ready to be handed over to the backend, which
|
|
performs the actual rendering calculations. +
|
|
-> more about the link:model/index.html[Model] +
|
|
-> design of the link:engine/index.html[Engine] subsystem
|
|
|
|
|
|
|
|
The Backend
|
|
~~~~~~~~~~~
|
|
|
|
The backend uses the low-level model and the _render jobs_ generated by Proc.
|
|
It actually performs 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. +
|
|
-> link:backend/index.html[Backend design level documents] +
|
|
-> link:{ldoc}/technical/backend/index.html[technical documentation] +
|
|
|
|
|
|
Extra Components
|
|
----------------
|
|
|
|
The Application
|
|
~~~~~~~~~~~~~~~
|
|
|
|
The application controls the initialization and shutdown procedures as well as
|
|
loading external elements such as plugins, which are widely used throughout
|
|
Lumiera. It acts as the framework which supports core component operations. This
|
|
framework is complemented by a library of commonly used components, algorithms and data structures. +
|
|
-> link:application/index.html[Application framework]
|
|
|
|
|
|
link:plugins/index.html[Plugins]
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Plugins play an important role within Lumiera since the application relies
|
|
heavily on current FLOSS implementations and external libraries. Moreover, the
|
|
application is envisioned to be configurable and can be extended in various
|
|
ways; whenever some extension isn't permanent or will be used only on demand, it
|
|
is packaged as a separate module into a plug-in. For example, the GUI of Lumiera
|
|
is a plugin. +
|
|
-> design doruments regarding the link:plugins/index.html[Plugins]
|
|
|