benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

create pages and sections for the design of output handling and player subsystem

Browse source 
Signed-off-by: Ichthyostega <prg@ichthyostega.de>
This commit is contained in:
Fischlurch 2011-05-22 05:45:59 +02:00
parent 51b3f0defa
commit c6f4f9bf25
4 changed files with 48 additions and 29 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
doc/design/architecture/playRender.txt
View file

@ -70,8 +70,8 @@ proceeding along a timeline).
Reconfiguration Reconfiguration
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^
Some of these operation modes need to be prepared to an unpredictable live reconfiguration, Some of these operation modes need to be prepared to encounter an unpredictable live
driven by user interactions: reconfiguration, driven by user interactions:
- any part of background rendering can be invalidated and restarted, while other parts - any part of background rendering can be invalidated and restarted, while other parts
should be re-integrated, possibly with adjusted position should be re-integrated, possibly with adjusted position
@ -108,7 +108,7 @@ playback location, and it can be hooked up with a play-control GUI widget
Each play-controller in turn gets associated with several *play/render-processes*, Each play-controller in turn gets associated with several *play/render-processes*,
one for each independent media stream (channel) to be produced. Of course this one for each independent media stream (channel) to be produced. Of course this
isn't an operating system process; rather, ach such process is a compound of entries isn't an operating system process; rather, each such process is a compound of entries
in a registration table, which serve the purpose of tying several other services together, in a registration table, which serve the purpose of tying several other services together,
which we initiate and use in order to make that render process happen. which we initiate and use in order to make that render process happen.
Most notably, we'll use the services of the actual engine, which provides us with kind of Most notably, we'll use the services of the actual engine, which provides us with kind of
@ -126,7 +126,7 @@ Viewer and Output connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Creating a player instance binds together three partners: a _timeline_, a _viewer_ Creating a player instance binds together three partners: a _timeline_, a _viewer_
and _the engine_. While the timeline provides the content to play, the _viewer connection_ and _the engine_. While the timeline provides the content to play, the _viewer connection_
is crutial for working out the actual output sink(s) and thus the output format to use. is crucial for working out the actual output sink(s) and thus the output format to use.
Thus, a viewer connection is prerequisite for creating a player instance. Thus, a viewer connection is prerequisite for creating a player instance.
Viewer connections exist as associations in the session/model -- as entities separate Viewer connections exist as associations in the session/model -- as entities separate
@ -135,13 +135,13 @@ such a connection is (still) missing, building a player instance recurs to the s
to get a suitable viewer _allocated_. The viewer connection can't be broken during the to get a suitable viewer _allocated_. The viewer connection can't be broken during the
lifetime of that player instance (or putting it the other way: breaking that viewer lifetime of that player instance (or putting it the other way: breaking that viewer
connection, e.g. by forcing a different connection or by shutting down the viewer, connection, e.g. by forcing a different connection or by shutting down the viewer,
immediately terminates the player. This detaching works synchroneously, i.e. it immediately terminates the player. This detaching works synchronously, i.e. it
blocks untlil all the allocated _output slots_ could be released. blocks until all the allocated _output slots_ could be released.
Live switching Live switching
^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
While the viewer connection can be treated as fixed during the lifespan of a player While the viewer connection can be treated as fixed during the lifespan of a player
instance, several life switching and reconfiguration operations might happen anytime: instance, several life switching and reconfiguration operations might happen any time:
The _model port_ (place where data is retrieved from calculation), the output characteristics The _model port_ (place where data is retrieved from calculation), the output characteristics
(framerate, direction) and the delivery goals (playback position, loop playing, scrubbing) (framerate, direction) and the delivery goals (playback position, loop playing, scrubbing)
all may be changed during playback -- we need a way for the player to ``cancel'' and all may be changed during playback -- we need a way for the player to ``cancel'' and
@ -164,7 +164,7 @@ the quantisation, which leaves us with just a few possible junction points
where to place quantisation: The backend, the GUI, the player, the session. where to place quantisation: The backend, the GUI, the player, the session.
- putting it into the backend seems to be the most reasonable at first sight: - putting it into the backend seems to be the most reasonable at first sight:
We can ``do away'' with nasty things soon, especially if they are technicallities, We can ``do away'' with nasty things soon, especially if they are technicalities,
``get a clean state soon'' -- and hasn't frame quantisation something to do ``get a clean state soon'' -- and hasn't frame quantisation something to do
with media data, which is handled in the backend? with media data, which is handled in the backend?
+ +
@ -174,7 +174,7 @@ amount of degraded information flows throughout the whole system; thus the
general rule to do it as late as possible. Uncrippled information is general rule to do it as late as possible. Uncrippled information is
enablement. And last but not least: the frame quantisation is connected enablement. And last but not least: the frame quantisation is connected
to the _output_ format -- and the backend is likely within the whole to the _output_ format -- and the backend is likely within the whole
application the subsytem most remote and unaware of output requirements. application the subsystem most remote and unaware of output requirements.
- rounding/quantising in the GUI is extremely common within media applications; - rounding/quantising in the GUI is extremely common within media applications;
unfortunately there seems to be not a single rational argument supporting that habit. unfortunately there seems to be not a single rational argument supporting that habit.
@ -184,7 +184,7 @@ Which leaves us with the player and the session. Both positions could
arguably be supported. Here, a more careful consideration shows, that arguably be supported. Here, a more careful consideration shows, that
the ``act of frame rounding'' can be decomposed: into the _act of quantisation_ the ``act of frame rounding'' can be decomposed: into the _act of quantisation_
and the _frame grid:. Basically its the session which has the ability and the _frame grid:. Basically its the session which has the ability
to form the *frame grid*, but it is lacking crutial information about to form the *frame grid*, but it is lacking crucial information about
the output. Only when connecting both -- which is the essence of the the output. Only when connecting both -- which is the essence of the
player -- frame quantisation can actually be performed. Thus, the player -- frame quantisation can actually be performed. Thus, the
player is the natural location to perform that quantisation operation. player is the natural location to perform that quantisation operation.

15
doc/design/engine/OutputHandling.txt Normal file
View file

@ -0,0 +1,15 @@
Design: Output Handling
=======================
:Date: June 2011
:Author: Ichthyostega
//Menu: label Output handling
Some ideas....
- abstract away the actual technology used for output
- have generic *output designations* and translate them into an *output slot*
- the OutputSlot interface can be designed to match the requirements of the Engine
- assume a mechanism to handle timeouts, glitches and skips within each concrete OutputSlot implementation

3
doc/design/engine/index.txt
View file

@ -1,5 +1,6 @@
Design Documents: Renderengine Design Documents: Renderengine
============================== ==============================
Eventually, this will have design documentation for the Engine. This section contains design documents regarding the overall workings of the Render Engine,
and the handling of output generation and output connections.

39
doc/user/intro/intro.txt
View file

@ -1,6 +1,7 @@
Lumiera (as seen) from Outer Space Lumiera (as seen) from Outer Space
================================== ==================================
:Author: Christian Thäter ct@pipapo.org :Author: Christian Thäter ct@pipapo.org
:Author: Hermann Voßeler Ichthyostega@web.de
:Date: Summer 2010 :Date: Summer 2010
@ -18,13 +19,10 @@ they get to work with. It is aimed for workflow designers any anyone who wants
to know how the program works in general. to know how the program works in general.
****************************************************************************** ******************************************************************************
About this Document
-------------------
// all things starting with '//' are asciidoc comments and drafts/notes while // all things starting with '//' are asciidoc comments and drafts/notes while
// working on this document // working on this document
.About this Document
This document is meant to be read electronically, it contains a lot This document is meant to be read electronically, it contains a lot
hyper-links between explanations denoted by an arrow ->. Lumiera is still in hyper-links between explanations denoted by an arrow ->. Lumiera is still in
development, we describe here planned features without explicitly tagging them; development, we describe here planned features without explicitly tagging them;
@ -38,8 +36,13 @@ Vision
// objective and goals of the project // objective and goals of the project
Lumiera claims to be `professional', this is quite a vague term and needs Lumiera claims to be a _professional non-linear video editor_. To start with, we should
some explanation what it means to us: point out that ``professional'' does not necessarily mean ``commercial'' or ``industrial''.
It's more of an attitude or mindset -- doing work seriously, and to be subject to any
kind of wider goal, demand, or purpose. When it comes to editing film, this might be
artistry, a narration or meaning to convey, a political message or something to show
to your audience. Anyhow, for the tools, the editing software used to this end,
we can identify several properties and requirements, to be labeled ``professional'':
Reliability:: Reliability::
Whatever happens, your work must be safe, protected against software Whatever happens, your work must be safe, protected against software
@ -47,34 +50,34 @@ some explanation what it means to us:
never crash, in practice even crashes or power outages should not never crash, in practice even crashes or power outages should not
result in lost work. result in lost work.
Productivity:: Quality::
If you work with high quality, cinema grade digital video material you
want to be sure that you can deliver crisp quality without compromise,
throughout the whole workflow to your final product. All rendering
must be reproducible to the bit.
Performance and Productivity::
Professionals want to get things done, in time, but optionally with control Professionals want to get things done, in time, but optionally with control
over every aspect. Balancing these goals should be the central concern for over every aspect. Balancing these goals should be the central concern for
workflow design and usability. workflow design and usability.
Quality:: Scalability and Adaptability::
If you work with high quality, cinema grade digital video material you
want to be sure that you can deliver this crisp quality without
compromise throughout you workflow to your final product. All rendering
must be reproducible to the bit.
Scalability::
Projects and budgets differ, hardware advances, Lumiera must scale Projects and budgets differ, hardware advances, Lumiera must scale
in different dimensions and use the available resources as best as it in different dimensions and use the available resources as best as it
can. From small Laptops to multicore Computers and Renderfarms. can. From small Laptops to multi core computers and Renderfarms.
Future Proofness:: Durability::
Soft and Hardware advances at a fast pace. We must not lock into the Soft and Hardware advances at a fast pace. We must not lock into the
current state of technology but being flexible to extend the System current state of technology but being flexible to extend the System
without breaking compatibility. Projects you create nowadays with without breaking compatibility. Projects you create nowadays with
Lumiera should be usable in foreseeable future, at least there needs Lumiera should be usable in foreseeable future, at least there needs
to be a guaranteed upgrade path. to be a guaranteed upgrade path.
<
Fundamental Forces Fundamental Forces
------------------ ------------------
// the basic ideas which drive the lumiera design // the basic ideas which drive the Lumiera design
The Lumiera design is guided by a small number of basic principles. Keeping The Lumiera design is guided by a small number of basic principles. Keeping
these in mind will help to understand how actually more interesting things can these in mind will help to understand how actually more interesting things can