combine recent documentation improvements done by Benny and Hendrik
resolved some edit conflicts in doc/user/intro/intro.txt
This commit is contained in:
commit
3d03c19e04
6 changed files with 42 additions and 43 deletions
|
|
@ -1,22 +1,22 @@
|
|||
Design Documents: Backend
|
||||
=========================
|
||||
|
||||
What follows is a summary regarding the design of Lumiera's *Data Handling Backend*
|
||||
What follows is a summary of Lumiera's *Data Handling Backend*
|
||||
|
||||
This is the foundation layer responsible for any high performance or high volume
|
||||
data access. Within Lumiera, ther are two main kinds how data is handled:
|
||||
data access. Within Lumiera, there are two main kinds of data handling:
|
||||
|
||||
* The Session and the object models manipulated through the GUI is kept in memory.
|
||||
It is backed by a _storage backend,_ which provides database like storage and
|
||||
* The Session and the object models manipulated through the GUI are kept in memory.
|
||||
They are backed by a _storage backend,_ which provides database-like storage and
|
||||
especially logging, replaying and ``Undo'' of all ongoing modifications..
|
||||
* Media data is handled _frame wise_ -- as described below.
|
||||
|
||||
The backend uses *memory mapping* to make data available to the program.
|
||||
This is somewhat different to the more common open/read/write/close file access,
|
||||
while giving superior performance and much better memory utilization.
|
||||
The data backend must be capable to handle more data than will fit into the memory
|
||||
The data backend must be able to handle more data than will fit into the memory
|
||||
or even address space on 32 bit architectures. Moreover, a project might access more files
|
||||
than the OS can handle at a any time, thus the for _Files used by the Backend,_ it needs a
|
||||
than the OS can keep open simultaneously, thus the for _Files used by the Backend,_ it needs a
|
||||
*FilehandleCache* to manage file handle dynamically.
|
||||
|
||||
Which parts of a file are actually mapped to physical RAM is managed by the kernel;
|
||||
|
|
|
|||
|
|
@ -10,18 +10,19 @@ Lumiera Design Documents
|
|||
// Menu : append child plugins
|
||||
// Menu : append child workflow
|
||||
|
||||
The goal of Lumiera is to provide a professional tool for video editing on
|
||||
Lumiera is 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. 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.
|
||||
for the core of a Non-Linear Editing software. A key aspect of Lumiera
|
||||
is strong separation between the user interface and the processing core.
|
||||
Lumiera will have a GTK GUI but that will not be
|
||||
exclusive; other GUIs can be written, even by users,
|
||||
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.
|
||||
as a processing core will be able to perform any conceivable
|
||||
task on video and audio, even some unrelated to video editing.
|
||||
|
||||
.Workflow
|
||||
*****************
|
||||
|
|
@ -35,19 +36,19 @@ 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.
|
||||
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.
|
||||
|
||||
Graphical User Interface
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
User interfaces are basically implemented as a plugin. As a consequence, it is
|
||||
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 closest component to the user. It is
|
||||
a purely visual interaction with the user. There the user manipulates,
|
||||
specialised GUIs. The interface is the component that is closest to the user. It
|
||||
provides 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]
|
||||
|
|
@ -56,10 +57,10 @@ objects) and Assets. These elements are contained within a structure called the
|
|||
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
|
||||
The processing layer (``Proc-layer'' or ``proc'') has several closely related aspects.
|
||||
When 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,
|
||||
operations initiated by the user are actually performed there. 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
|
||||
|
|
@ -89,7 +90,7 @@ The Application
|
|||
~~~~~~~~~~~~~~~
|
||||
|
||||
The application controls the initialization and shutdown procedures as well as
|
||||
loading external elements such as plugins, which are widely used throughout
|
||||
loading external elements such as plug-ins, 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]
|
||||
|
|
@ -98,11 +99,11 @@ framework is complemented by a library of commonly used components, algorithms a
|
|||
link:plugins/index.html[Plugins]
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Plugins play an important role within Lumiera since the application relies
|
||||
Plug-ins 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
|
||||
application will 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]
|
||||
-> design documents regarding the link:plugins/index.html[Plugins]
|
||||
|
||||
|
|
|
|||
|
|
@ -2,4 +2,5 @@ Design Documents: Model
|
|||
=======================
|
||||
|
||||
* two models: high-level and low-level
|
||||
* RfC: link:{rfc}/../rfc_pending/ProcHighLevelModel.html[high-level model basics]
|
||||
* RfC: link:{rfc}/../rfc/ProcHighLevelModel.html[high-level model basics]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
|
||||
= Documentation =
|
||||
|
||||
This documentation section contains documentation for both users and developers.
|
||||
|
|
@ -29,7 +30,7 @@ used as design notebook, featuring day-to-day design sketches, notes but also
|
|||
quite some more persistent planning. Finished documentation text is constantly
|
||||
moved over to the documentation section(s) of the Lumiera website.
|
||||
|
||||
-> access the Proy-Layer link:http://lumiera.org/wiki/renderengine.html[TiddlyWiki online here]
|
||||
-> access the Proc-Layer link:http://lumiera.org/wiki/renderengine.html[TiddlyWiki online here]
|
||||
|
||||
|
||||
== Media and Presentations ==
|
||||
|
|
|
|||
|
|
@ -46,13 +46,11 @@ link:{ldoc}/technical/overview.html[The Inner Core]
|
|||
Vision
|
||||
------
|
||||
|
||||
NOTE: this section is still in discussion
|
||||
|
||||
Lumiera strives to be a *professional non-linear video editing system*. It is
|
||||
important to note that by ``professional'' we do not imply ``commercial'' nor
|
||||
``industrial''. We do, however, wish to convey an attitude or frame of mind in
|
||||
the approach made to such work; not its goal, requirement or purpose.
|
||||
|
||||
``industrial''. We do, however, wish to convey an attitude or frame of mind
|
||||
in the approach made to such work; not its goal or purpose.
|
||||
|
||||
Professionalism implies _doing work with sincerity and being subject to any
|
||||
kind of wider goal, demand, or purpose._ When it comes to editing film, this
|
||||
wider goal, demand, or purpose might be artistry, a narration or have meaning to
|
||||
|
|
@ -74,12 +72,10 @@ aspects film production tools will have to exhibit to aspire to be labelled
|
|||
requires crisp-quality results with no concessions made throughout the
|
||||
entire workflow that might compromise quality of the final work.
|
||||
A common requirement is the ability to reproduce all rendering
|
||||
calculations down to a single digit.
|
||||
|
||||
??What does this mean, a single digit??
|
||||
calculations down to the last bit.
|
||||
|
||||
Performance and Productivity::
|
||||
Professionals want to get things done on time ??and content??, but
|
||||
Professionals want to get things done on time, but
|
||||
with control over all detail. The fine balance of these goals is a
|
||||
central goal of workflow design and usability.
|
||||
|
||||
|
|
@ -149,8 +145,8 @@ Processing video (and audio) data can be conceived as a graph (more precisely
|
|||
a _directed acyclic graph_). In this model of video processing, data flows
|
||||
along the edges of the graph and is processed at the nodes.
|
||||
|
||||
The following figure depicts manipulating video data as a graph. The nodes of
|
||||
the ??root?? of the graph are where data input occurs. From there, the data moves on
|
||||
The following figure depicts manipulating video data as a graph. The nodes at
|
||||
the top of the graph are where data input occurs. From there, the data moves on
|
||||
to the next nodes: the direct siblings of the root. Here, the video data is
|
||||
pre-processed. All other operations on the data can be represented by
|
||||
nodes, and data flows from one operation to the next along the nodes of the
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
Lumiera User Manual
|
||||
===================
|
||||
|
||||
The plan is to create the users manual later in a colaborative
|
||||
fashion, similar to what turned out so effective for Cinelerra.
|
||||
The plan is to create the users manual later in a collaborative
|
||||
fashion, which was effective for Cinelerra.
|
||||
|
||||
This work is postponed until the software is actually working.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue