formatting fixes for existing RfCs
This commit is contained in:
parent
1ce29b7d3c
commit
ef95048de0
10 changed files with 72 additions and 26 deletions
|
|
@ -41,8 +41,8 @@ _corresponds to a single data stream_ to be rendered. Thus, when the play
|
|||
in _playing_ or _paused_ state, typically multiple corresponding render
|
||||
processes exist.
|
||||
|
||||
* there is an displayer- or output slot, which got allocated on creation of the
|
||||
process
|
||||
* there is an displayer- or output slot, which got allocated on creation
|
||||
of the process
|
||||
* the process disposes calculated data frames "into" this slot
|
||||
* the process can be paused/started and stopped (aborted, halted).
|
||||
* some processes allow for changing parameters dynamically (e.g. speed,
|
||||
|
|
@ -52,23 +52,31 @@ processes exist.
|
|||
|
||||
.Process parameters
|
||||
A process is linked to a single stream data format (a ->
|
||||
link:StreamTypeSystem.html[stream implementation type]). + It is configured
|
||||
with _frame quantisation_ and _timings_, and a _model port_ identifier and
|
||||
_channel selector_.
|
||||
link:StreamTypeSystem.html[stream implementation type]). +
|
||||
It is configured with _frame quantisation_ and _timings_, and a _model port_
|
||||
identifier and _channel selector_.
|
||||
|
||||
quantisation::
|
||||
translates time values into frame numbers. (In the most general
|
||||
case this is a function, connected to the session)
|
||||
|
||||
timings::
|
||||
a definition to translate global model time units in real clock time,
|
||||
including _alignment_ to an external time grid.
|
||||
|
||||
model port::
|
||||
a point in the (high level) model where output can be produced. +
|
||||
This might be a global pipe in one of the model's timelines, or
|
||||
it might be a _probe point_.
|
||||
|
||||
channel::
|
||||
within the session and high level model, details of the stream
|
||||
implementation are abstracted. Typically, a global pipe (master bus
|
||||
or subgroup) corresponds to a multichannel stream, and each of these
|
||||
channels might be hooked up to an individual render process
|
||||
(we have to work out if that's _always the case_ or just under
|
||||
_some circumstances_)
|
||||
|
||||
quantisation:: translates time values into frame numbers. (In the most general
|
||||
case this is a function, connected to the session) timings:: a definition to
|
||||
translate global model time units in real clock time, including _alignment_ to
|
||||
an external time grid. model port:: a point in the (high level) model where
|
||||
output can be produced. +
|
||||
This might be a global pipe in one of the model's timelines, or
|
||||
it might be a _probe point_.
|
||||
channel:: within the session and high level model, details of the stream
|
||||
implementation are abstracted. Typically,
|
||||
a global pipe (master bus or subgroup) corresponds to a multichannel
|
||||
stream, and each of these channels might be hooked up to an
|
||||
individual render process (we have to work out if that's _always the
|
||||
case_ or just under _some circumstances_)
|
||||
|
||||
[NOTE]
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -58,6 +58,11 @@ Tasks
|
|||
^^^^^
|
||||
|
||||
|
||||
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
|
||||
|
|
@ -75,7 +80,7 @@ Alternatives
|
|||
|
||||
Rationale
|
||||
~~~~~~~~~
|
||||
|
||||
TBD
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -109,6 +109,11 @@ Tasks
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
* with just one concept, we get a lot of issues right, which many conventional
|
||||
|
|
|
|||
|
|
@ -32,6 +32,11 @@ Tasks
|
|||
^^^^^
|
||||
|
||||
|
||||
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
|
||||
|
|
|
|||
|
|
@ -73,6 +73,11 @@ Tasks
|
|||
// * item ...
|
||||
|
||||
|
||||
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
// add just a fact list/enumeration which make this suitable:
|
||||
|
|
@ -88,7 +93,7 @@ Cons
|
|||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
^^^^^^^^^^^^
|
||||
//alternatives: if possible explain/link alternatives and tell why they are not
|
||||
viable:
|
||||
|
||||
|
|
|
|||
|
|
@ -134,6 +134,11 @@ Tasks
|
|||
// * item ...
|
||||
|
||||
|
||||
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
// add just a fact list/enumeration which make this suitable:
|
||||
|
|
@ -149,7 +154,7 @@ Cons
|
|||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
^^^^^^^^^^^^
|
||||
//alternatives: if possible explain/link alternatives and tell why they are not
|
||||
viable:
|
||||
|
||||
|
|
|
|||
|
|
@ -136,6 +136,11 @@ Please review and discuss this proposal, consider if it's of any use setting it
|
|||
up this way...
|
||||
|
||||
|
||||
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
* doesn't hinder us
|
||||
|
|
|
|||
|
|
@ -10,8 +10,7 @@
|
|||
Stream Type System
|
||||
------------------
|
||||
Especially in the Proc-Layer, we need a framework to deal with different
|
||||
"kinds" of media streams.
|
||||
+
|
||||
"kinds" of media streams. +
|
||||
This is the foundation to be able to define what can be connected and to
|
||||
separate out generic parts and isolate specific parts.
|
||||
|
||||
|
|
@ -69,7 +68,7 @@ or selection regarding each of these levels.
|
|||
conversions. Examples for Prototypes are: stereoscopic (3D) video versus the
|
||||
common flat video lacking depth information, spatial audio systems
|
||||
(Ambisonics, Wave Field Synthesis), panorama simulating sound systems (5.1,
|
||||
7.1,...), stereophonic and monaural audio.
|
||||
7.1,...), binaural, stereophonic and monaural audio.
|
||||
* Besides the distinction by prototypes, there are the various *media
|
||||
implementation types*. This classification is not necessarily hierarchically
|
||||
related to the prototype classification, while in practice commonly there
|
||||
|
|
|
|||
|
|
@ -113,6 +113,11 @@ We have appstate::maybeWait() which already does such a loop. It needs to be
|
|||
extended by the proposed things above.
|
||||
|
||||
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
// add just a fact list/enumeration which make this suitable:
|
||||
|
|
@ -127,7 +132,7 @@ Cons
|
|||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
^^^^^^^^^^^^
|
||||
//alternatives: if possible explain/link alternatives and tell why they are not
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -114,6 +114,10 @@ Tasks
|
|||
// * item ...
|
||||
|
||||
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
// add just a fact list/enumeration which make this suitable:
|
||||
|
|
@ -129,7 +133,7 @@ Cons
|
|||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
^^^^^^^^^^^^
|
||||
//alternatives: explain alternatives and tell why they are not viable:
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue