ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

drafting elementary operations comprising the builder

Browse source
This commit is contained in:
Fischlurch 2007-12-04 05:19:27 +01:00
parent 3036d5cb56
commit 02c0ed9445
1 changed files with 30 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
wiki/renderengine.html
View file

@ -570,6 +570,30 @@ For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from
[img[how to implement Automation|uml/fig129669.png]]
</pre>
</div>
<div title="BasicBuildingOperations" modifier="Ichthyostega" modified="200712040413" created="200712040334" tags="design dynamic def" changecount="5">
<pre>Starting out from the concepts of Objects, Placement to Tracks, Ports and connection properties (&amp;rarr; see [[here|TrackPortEDL]]) within the EDL, we can identify the elementary operations occuring within the Builder. Overall, the Builder is organized as application of //visiting tools// to a collection of objects, so finally we have to consider some object kind appearing in the working function of the given builder tool, which holds at this moment some //context//. The job now is to organize this context such as to create a predictable build process from this //event driven// approach.
!Builder working Situations
# any ''Clip'' (which is at this point already reduced to a part of single elementary media stream)
## yields a source reading node
## which needs to be augmented by the underlying media's [[processing pattern|ProcPatt]]
##* thus inserting codec(s) and source transformations
##* effectively this is an application of effects
## followed by the application of effects
##* separately for every effect chain rooted (placed) directly onto the clip
##* and regarding the chaining order
## next we have to assess the [[ports|Port]] to which the clip has been placed
## producing a WiringRequest for every pair {{{(chainEndpoint, port)}}}
# attaching an ''Effect'' is actually always an //insertion operation// which is done by //prepending// to the previously built nodes
# treating an ''~WiringRequest'' means
## detecting possible and impossible connections
## deriving additional possible &quot;placement dimensions&quot; generated by executing such an connection (e.g. connecting a mono source to a spacial sound system bus creates panning possibilities)
##* deriving parameter sources for this additional degrees of freedom
##* fire off insertion of the necessary effects to satisfy this connection request and implement the additional &quot;placement dimensions&quot; (pan, layer order, overlay mode, MIDI channel selection...)
# processing effects and further placements ''attached to a Port'' behaves identical to the processing done with all attachements to individual clips.
After consuming all input objects and satisfying all wiring requests, the result is a set of [[exit nodes|ExitNode]] ready for pulling data. We call the network reachable from such an exit node a [[Processor]], together all processors of all segments and output data types comprise the render engine.
</pre>
</div>
<div title="BetterTimelineMacro" modifier="Saq" modified="200701030924" created="200607280926" tags="lewcidExtension systemConfig" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200701030924">
<pre>/***
|Name|BetterTimelineMacro|
@ -682,7 +706,7 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
}
//}}}</pre>
</div>
<div title="BuildProcess" modifier="MichaelPloujnikov" modified="200706271431" created="200706190658" tags="dynamic" changecount="21">
<div title="BuildProcess" modifier="Ichthyostega" modified="200712040318" created="200706190658" tags="dynamic" changecount="22">
<pre>All decisions on //how // the RenderProcess has to be carried out are concentrated in this rather complicated Builder Subsystem. The benefit of this approach is, besides decoupling of subsystems, to keep the actual performance-intensive video processing code as simple and transparent as possible. The price, in terms of increased complexity &amp;mdash; to pay in the Builder &amp;mdash; can be handled by making the Build Process generic to a large degree. Using a Design By Contract approach we can decompose the various decisions into small decision modules without having to trace the actual workings of the Build Process as a whole.
[&gt;img[Outline of the Build Process|uml/fig129413.png]]
@ -691,6 +715,7 @@ The building itself will be broken down into several small tool application step
* for each segment: generate a ProcNode for each found MObject and wire them accordingly
Note, //we still have to work out how exactly building, rendering and playback work// together with the backend-design. The build process as such doesn't overly depend on these decisions. It is easy to reconfigure this process. For example, it would be possible as well to build for each frame separately (as Cinelerra2 does), or to build one segment covering the whole timeline (and handle everything via [[Automation]]
&amp;rarr;see also: BasicBuildingOperations
&amp;rarr;see also: BuilderStructures
[img[Colaborations in the Build Process|uml/fig128517.png]]
@ -1004,7 +1029,7 @@ For this Cinelerra3 design, we could consider making GOP just another raw media
&amp;rarr;see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
</pre>
</div>
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200711300349" created="200708080322" tags="overview" changecount="12">
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200712040320" created="200708080322" tags="overview" changecount="13">
<pre>This wiki page is the entry point to detail notes covering some technical decisions, details and problems encountered in the course of the implementation of the Cinelerra Renderengine, the Builder and the related parts.
* [[Packages, Interfaces and Namespaces|InterfaceNamespaces]]
@ -1017,6 +1042,7 @@ For this Cinelerra3 design, we could consider making GOP just another raw media
* [[collecting Ideas for Implementation Guidelines|ImplementationGuidelines]]
* [[using the Visitor pattern?|VisitorUse]]
* [[Handling of Tracks and Ports in the EDL|TrackPortEDL]]
* [[identifying the basic Builder operations|BasicBuildingOperations]]
</pre>
</div>
<div title="ImplementationGuidelines" modifier="Ichthyostega" modified="200711210542" created="200711210531" tags="discuss draft" changecount="7">
@ -2905,7 +2931,7 @@ function addKeyDownHandlers(e)
</pre>
</div>
<div title="TrackPortEDL" modifier="Ichthyostega" modified="200712020310" created="200711300405" tags="design discuss def decision" changecount="6">
<div title="TrackPortEDL" modifier="Ichthyostega" modified="200712040319" created="200711300405" tags="design discuss def decision" changecount="8">
<pre>''towards a definition of »Track«''. We don't want to tie ourself to some naive and overly simplistic definition, just because it is convenient. For classical (analogue) media, tracks are physical entities dictated by the nature of the process by which the media works. Especially, Tape machines have read/writing heads, which creates fixed tracks to which to route the signals. This is a practical geometric necessity. For digital media, there is no such necessity. We are bound primarily by the editor's habits of working.
!!!Assessment of Properties
@ -2924,7 +2950,7 @@ __Tracks__ are just a structure used to organize the Media Objects within the ED
* placing onto a track associates the ~MObject with this track; the GUI will show it on this track and the track may be used to resolve other properties of the object.
* placing to a __Port__ brings the object in conjunction with this Port for the build process. It will be considered when building the render network for this port. Source-like objects (clips and exit nodes of effect chains) will be connected to the port, while transforming objects (effects) are inserted at the port.
* depending on the nature of the port and the source, placing to some port may create additional degrees of freedom, demanding the object to be placed in this additional dimensions: Connecting to video out e.g. creates an overlay mode and a layer position, while connecting to a spatial sound system creates a pan position. Placing a mono clip onto a mono Port creates no additional properties though.
Placements are __resolved__ resulting in an ExplicitPlacement. In most cases this is just a gathering of properties, but as Placements can be incomplete and relative, there is room for real solving. The resolving mechanism tries to __derive missing properties__ from the __context__: When a clip isn't placed to some port but to a Track, than the Track and its parents will be inspected. If some of them has been placed to a port, the object will be connected to this port. Similar for layers and pan position. This is done by [[Placement]] and LocatingPin; as the [[Builder]] uses ~ExplicitPlacements, he isn't concerned with this resolving and uses just the input he gets</pre>
Placements are __resolved__ resulting in an ExplicitPlacement. In most cases this is just a gathering of properties, but as Placements can be incomplete and relative, there is room for real solving. The resolving mechanism tries to __derive missing properties__ from the __context__: When a clip isn't placed to some port but to a Track, than the Track and its parents will be inspected. If some of them has been placed to a port, the object will be connected to this port. Similar for layers and pan position. This is done by [[Placement]] and LocatingPin; as the [[Builder]] uses ~ExplicitPlacements, he isn't concerned with this resolving and uses just the data they deliver to drive the [[basic building operations|BasicBuildingOperations]]</pre>
</div>
<div title="VisitorUse" modifier="Ichthyostega" modified="200711280312" created="200711280302" tags="impl discuss" changecount="11">
<pre>Using the ''Visitor Design Pattern'' is somewhat controversial, mainly because this pattern is rather complicated, requires certain circumstances to be usefull, and &amp;mdash; especially when used in the original form described by Gamma et al &amp;mdash; puts quite some burden on the implementor. This problems can be ameliorated by using library implementation techniques described by Robert Martin and implemented e.g. by Alexandrescu in the Loki library.