Merge commit 'pipapo'

wiki/backend.html

@@ -44,7 +44,7 @@ DAMAGE.
 
 <style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;"><b>My TiddlyWiki</b> is loading<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>
 <!--PRE-HEAD-END-->
-<title> Cinelerra3 Data Backend - design draft </title>
+<title> Data Backend - design draft </title>
 <style type="text/css">
 #saveTest {display:none;}
 #messageArea {display:none;}
@@ -764,10 +764,71 @@ TertiaryMid: #999
 TertiaryDark: #666
 Error: #f88</pre>
 </div>
+<div title="DataBackend" modifier="CehTeh" modified="200706192335" created="200706192251" changecount="3">
+<pre>This just starts as braindump, I will refine it soon:
+* handle all files cinelerra uses at runtime (media, edl, temp data)
+* manage filehandles, cinelerra might use more more files than available filehandles
+* manage temporary data
+* do caching
+* io will be blocked where the backend tells the core where it can expect the data (not read()/write() like)
+* kindof garbage collector
+* do prefetching
+* no/low latency for the core the prefetcher and other things ensure that data is available in time
+* translate any input into a format which the cinelerra core understands (demux, decode)
+* same for encoding to output formats
+* offer a plugin API for encoders/decoders
+* maybe network backend for serving data to distributed rendernodes
+* can do some load control or management (trigger adaptive rendering if system is idle etc)
+* pull based arch
+
+Look at [[Overview]] for the current design proposal</pre>
+</div>
 <div title="DefaultTiddlers" modifier="CehTeh" created="200706192002" changecount="1">
 <pre>DataBackend
 </pre>
 </div>
+<div title="File" modifier="CehTeh" modified="200706202209" created="200706201525" changecount="3">
+<pre>'File' is the superclass of all possible filetypes, it has a weak reference to a FileHandle which is managed in FileHandleCache, on creation only the existence (when reading) or access for write for new files are checked. 'File' stores some generic metadata about the underlying file and intended use. But actual opening is done on demand.
+
+Files content is memory mapped into the process address space, this is managed by FileMap objects and a FileMapCache.
+</pre>
+</div>
+<div title="FileHandle" modifier="CehTeh" modified="200706202208" created="200706201535" changecount="2">
+<pre>'FileHandle's are managed by the FileHandleCache, they are just storing the underlying OS file handles and managed in a lazy/weak way, (re)opened when needed and aging in the cache when not needed, since the amount of open file handles is limited aged ones will be closed and reused when the system needs to open another file.
+</pre>
+</div>
+<div title="FileHandleCache" modifier="CehTeh" modified="200706202209" created="200706201548" changecount="3">
+<pre>'FileHandleCache' storing a finite maximum number of [[FileHandle]]s as a list. As long the configured maximum of open files is not reached new file handles are stored at the begin of the list. Whenever a filehandle is accessed it is moved to the begin of the list too. Unused filehandles propagate towards the end of the list. When the maximum of open filehandles is reached, aged filehandles are closed and taken from the end.
+</pre>
+</div>
+<div title="FileMap" modifier="CehTeh" modified="200706202210" created="200706201921" changecount="4">
+<pre>Each 'FileMap' object contains many [[Frame]]s as well as metadata. The actual layout depends on the type of the [[File]]. Mappings need to be page aligned while [[Frame]]s can can be anywhere within a file and dynamic sized.
+
+All established [[FileMap]]s are managed in a FileMapCache. This is similar to the FileHandleCache but mappings which are in use are checked out of the aging list and thus become locked from aging/purging.
+
+FileMap objects are transparent to the application, it will only requests [[Frame]]s as in position and size (and some other parameters).
+</pre>
+</div>
+<div title="FileMapCache" modifier="CehTeh" created="200706202207" changecount="1">
+<pre>The 'FileMapCache' keeps a list of FileMaps which are currently not in use and subject of aging.
+Whenever a FileMap is in use, it is checked out into a in-use list where it is not subject of aging.
+</pre>
+</div>
+<div title="Frame" modifier="CehTeh" modified="200706202206" created="200706202115" changecount="4">
+<pre>'Frames' are the smallest datablocks handled by the Backend. The application tells the Backend to make [[File]]s availabe and then only requests Frames from the Backend, all other datastructures of the backend are private.
+
+Actually Frames are blocks of continous memory, they can be anything depending on the usage of the [[File]] (Video frames, encoder frames, blocks of sound samples).
+
+Frames are referenced by a smart-pointer like object which manages the lifetime and caching behaviour. There are 3 states such a frame reference can be:
+# readonly: the backing FileMap is checked out from the aging list, frames can be read
+# readwrite: the backing FileMap is checked out from the aging list, frames can be read and written (depends on the filemode as well)
+# weak: the FileMap object is checked back into the ageing list, the frame cant be accessed but we can try to transform a weak reference into a readonly or readwrite reference
+
+Frames can be addressed uniquely (needs to be worked out) whenever a frame is not available, the backend can initiate a (probably recursive) render for it.
+
+Accessing [[Frame]]s may add further renderjobs for related frames to the [[Prefetch]] task.
+</pre>
+</div>
 <div title="FullScreenPlugin" modifier="CehTeh" modified="200706110313" created="200607241016" tags="systemConfig lewcidExtension" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706110313">
 <pre>/***
 |Name|FullScreenPlugin|
@@ -1164,6 +1225,35 @@ DataBackend
 
 &lt;style type=&quot;text/css&quot;&gt;#contentWrapper {display:none;}&lt;/style&gt;&lt;div id=&quot;SplashScreen&quot; style=&quot;border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;&quot;&gt;&lt;b&gt;My TiddlyWiki&lt;/b&gt; is loading&lt;blink&gt; ...&lt;/blink&gt;&lt;br&gt;&lt;br&gt;&lt;span style=&quot;font-size: 14px; color:red;&quot;&gt;Requires Javascript.&lt;/span&gt;&lt;/div&gt;</pre>
 </div>
+<div title="Notes" modifier="CehTeh" modified="200706200110" created="200706200107" changecount="2">
+<pre>how is FileMetadata kept
+
+copying semantics of smart pointers
+
+explain opening/closing files (use() forget()?)
+
+difference between actual files and temporary. does it make sense to have temporary storage on diffent speed disks?
+
+statistics hit/fail max/min/avg timings, hard / soft fails, timing constraints, when is rerendering cheaper than caching?..
+
+adaptive rendering
+
+background rendering
+
+renderfarm</pre>
+</div>
+<div title="Overview" modifier="CehTeh" modified="200706202210" created="200706200040" changecount="6">
+<pre>Whenever cinelerra needs to access data this is done through the DataBackend described here. The backend uses memory mapping to make data available to the program. This is little different to 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 or even address space on 32 bit archs.  Moreover a project may access more files than the OS can handle at a time, thus the for [[File]]s used by the Backend it needs a FileHandleCache to manage filehandles dynamically.
+
+Which parts of a File are actually mapped to physical ram is managed by the kernel, to keep a FileMapCache to manage the [[FileMap]]s we've set up.
+
+To minimize latency and optimize cpu utilization we have a [[Prefetch]] thread which operates a [[Scheduler]] to render and cache frames which are expected to be consumed soon. This prefetcher keeps [[Statistics]] for optimizing performance.
+
+The core accesses data through smart pointers which are described in [[DataLocking]].
+</pre>
+</div>
 <div title="PageTemplate" modifier="CehTeh" modified="200706110330" created="200701131624" tags="MPTWTheme" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706110330">
 <pre>&lt;!--{{{--&gt;
 &lt;div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'&gt;
@@ -1965,12 +2055,15 @@ see : &lt;&lt;tag RSSFeed&gt;&gt; for the full list.
 
 </pre>
 </div>
+<div title="SideBarOptions" modifier="CehTeh" created="200706200047" changecount="1">
+<pre>&lt;&lt;search&gt;&gt;&lt;&lt;closeAll&gt;&gt;&lt;&lt;permaview&gt;&gt;&lt;&lt;newTiddler&gt;&gt;&lt;&lt;saveChanges&gt;&gt;&lt;&lt;slider chkSliderOptionsPanel OptionsPanel &quot;options »&quot; &quot;Change TiddlyWiki advanced options&quot;&gt;&gt;</pre>
+</div>
 <div title="SiteSubtitle" modifier="CehTeh" modified="200706192003" created="200706192002" changecount="2">
 <pre>design draft
 </pre>
 </div>
-<div title="SiteTitle" modifier="CehTeh" created="200706192003" changecount="1">
+<div title="SiteTitle" modifier="CehTeh" modified="200706192245" created="200706192003" changecount="2">
-<pre>Cinelerra3 Data Backend</pre>
+<pre>Data Backend</pre>
 </div>
 <div title="SplashScreenPlugin" modifier="Saq" modified="200607202048" created="200607191631" tags="lewcidExtension systemConfig" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200607202048">
 <pre>/***

wiki/ichthyo-draft.html

@@ -747,8 +747,8 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
 }
 //}}}</pre>
 </div>
-<div title="BuildProcess" modifier="Ichthyostega" created="200706190658" changecount="1">
+<div title="BuildProcess" modifier="MichaelPloujnikov" modified="200706200523" created="200706190658" changecount="2">
-<pre>All decisions on //how// the RenderProcess has to be carried out are concentrated in this rather complicated Builder Subsystem. The benefit of this aproach is, besides decoupling of subsystems, to keep the actually performance relevant video processing code so simple and transparent as possible. The price in terms of increased complexity to pay here in the Builder can be handled by making the Build Process genereic to a large degree, thus beeing able to decompose the various decisions into small decision modules, which can be judged solely by a Design By Contract aproach, without having to trace the actual workings of the Build Process as a whole.
+<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 actuall performance-intensive video processing code as simple and transparent as possible. The price, in terms of increased complexity, to pay in the Builder 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.
 
 [img[Colaborations in the Build Process|renderengine/fig3.png]]</pre>
 </div>
@@ -1159,10 +1159,10 @@ config.formatters.push( {
 } )
 //}}}</pre>
 </div>
-<div title="MObjects" modifier="Ichthyostega" created="200706190636" changecount="1">
+<div title="MObjects" modifier="MichaelPloujnikov" modified="200706200508" created="200706190636" changecount="2">
 <pre>The MObjects Subsystem contains everything related to the EDL and the various Media Objects placed within it.
 
-This Design strives at a StrongSeparation between the low-level Structures used to carry out the actual rendering and the high level Entities living in the EDL and beeing manipulated by the user. In this high level view, the Objects are grouped and located by [[Placements]], providing a flexible and open way to express different groupings, locatons and ordering constraints between the Media Objects.
+This Design strives to achieve a StrongSeparation between the low-level Structures used to carry out the actual rendering and the high level Entities living in the EDL and being manipulated by the user. In this high level view, the Objects are grouped and located by [[Placements]], providing a flexible and open way to express different groupings, locations and ordering constraints between the Media Objects.
 
 [img[Classess related to the EDL|renderengine/fig2.png]]</pre>
 </div>
@@ -1183,11 +1183,11 @@ This Design strives at a StrongSeparation between the low-level Structures used
 <div title="Overview" modifier="Ichthyostega" created="200706190300" changecount="1">
 <pre>[img[Block Diagram|renderengine/fig1.png]]</pre>
 </div>
-<div title="OverviewRenderEngine" modifier="Ichthyostega" modified="200706190706" created="200706190647" changecount="4">
+<div title="OverviewRenderEngine" modifier="MichaelPloujnikov" modified="200706200529" created="200706190647" changecount="6">
-<pre>Render Engine, [[Builder]] and [[Controller]] are closely related Subsystems. Actually, the [[Builder]] //creates// a newly configurated Render Engine //for every// RenderProcess. For doing so, he queries from the Session (or, to be more preciese, from the [[Fixture]] within the current Session all necessary Media Object Placement informations and derives from this informations the actual assembly of ProcessingNodes comprising the Render Engine. Thus:
+<pre>Render Engine, [[Builder]] and [[Controller]] are closely related Subsystems. Actually, the [[Builder]] //creates// a newly configured Render Engine //for every// RenderProcess. Before doing so, he queries from the Session (or, to be more precise, from the [[Fixture]] within the current Session) all necessary Media Object Placement information. The [[Builder]] then derives from this information the actual assembly of ProcessingNodes comprising the Render Engine. Thus:
- * the source of the build process is a sequence of absolute (explicite) [[Placements]] called the [[Playlist]]
+ * the source of the build process is a sequence of absolute (explicit) [[Placements]] called the [[Playlist]]
- * the [[build process|BuildProcess]] is driven, configured and controlled by the [[Controller]] subsystem components, encompasing the actual playback configuration and State of the Sytem
+ * the [[build process|BuildProcess]] is driven, configured and controlled by the [[Controller]] subsystem component. It encompasses the actual playback configuration and State of the System.
- * the resulting Render Engine is a list of [[Processors]], each configured to calculate a segment of the timeline with a uniform properties, and each of this Processors in turn is a graph of interconnected ProcessingNodes.
+ * the resulting Render Engine is a list of [[Processors]], each configured to calculate a segment of the timeline with uniform properties. Each of these Processors in turn is a graph of interconnected ProcessingNodes.
 
 see also: RenderEntities
 
@@ -1994,17 +1994,17 @@ see : &lt;&lt;tag RSSFeed&gt;&gt; for the full list.
 
 </pre>
 </div>
-<div title="RenderEngine" modifier="Ichthyostega" modified="200706190701" created="200706190056" changecount="12">
+<div title="RenderEngine" modifier="MichaelPloujnikov" modified="200706200507" created="200706190056" changecount="13">
-<pre>The key idea of Ichthyo's Design-draft is, to use the ''Builder Pattern'' for the Render Engine, thus separating completely the //building// of the Render Pipeline from //running,// i.e. doing the actual Render. The Nodes in this Pipeline should process Video/Audio and do nothing else. No more any decisions, tests and conditional operations when running the Pipeline. Move all of this out into the configuration of the pipeline, done by the Builder. Make the actual processing nodes Template classes, parametrised by the color model and number of components. Make all Nodes on equal footing of each other, able to be connected freely within the limitations of the necessary input and output. Make the OpenGL rendering into alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus facturing out all the complexities of managing the data flow between core and hardware accelerated rendering out of the implementation of the actual processing. Introduce separate control data connections for the automation data, separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or two nodes using the sama automation data). Unfold any &quot;internal-multi&quot; effects into separate instances, e.g. the possibility of having an arbitrary number of single masks at any point of the pipeline instead of having one special masking facility encompassing multiple sub-masks.
+<pre>The key idea of Ichthyo's Design-draft is, to use the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]] for the Render Engine, thus separating completely the //building// of the Render Pipeline from //running,// i.e. doing the actual Render. The Nodes in this Pipeline should process Video/Audio and do nothing else. No more decisions, tests and conditional operations when running the Pipeline. Move all of this out into the configuration of the pipeline, which is done by the Builder. Make the actual processing nodes Template classes, parametrized by the color model and number of components. Make all Nodes of equal footing with each other, able to be connected freely within the limitations of the necessary input and output. Make the OpenGL rendering into alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus factoring out all the complexities of managing the data flow between core and hardware accelerated rendering out of the implementation of the actual processing. Introduce separate control data connections for the automation data, separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or two nodes using the same automation data). Unfold any &quot;internal-multi&quot; effects into separate instances, e.g. the possibility of having an arbitrary number of single masks at any point of the pipeline instead of having one special masking facility encompassing multiple sub-masks.
 
 !Why doesn't the current Design succeed with this?
 The design of Cinelerra 2 basically follows this design, but __fails because of two reasons__
  * too much differentiation is put into the class hierarchy instead of configuring Instances differently. 
    This causes overly heavy use of virtual functions and -- in order to ameliorate this -- falling back to hard wired branching
- * far too much back-coupling to the internals of the EDL, forcing a overly rigid structure on the latter
+ * far too much back-coupling to the internals of the [[EDL|http://en.wikipedia.org/wiki/Edit_decision_list]], forcing a overly rigid structure on the latter
 
 !Try to learn from this
- * build up an NodeAbstraction powerfull enough to express //all necessarey Operations// without the need to recure on the actual object type
+ * build up an NodeAbstraction powerful enough to express //all necessary Operations// without the need to recure on the actual object type
  * need to redesign the internals of the EDL in a far more open manner. See MObjects
  * strive at a StrongSeparation between EDL and Render Engine
 
@@ -2014,8 +2014,8 @@ The design of Cinelerra 2 basically follows this design, but __fails because of
  * BuildProcess
  * RenderProcess</pre>
 </div>
-<div title="RenderEntities" modifier="Ichthyostega" created="200706190715" changecount="1">
+<div title="RenderEntities" modifier="MichaelPloujnikov" modified="200706200519" created="200706190715" changecount="2">
-<pre>As said, the Render Engine carries out the low-level and percormance critical tasks solely; all configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of ProcessingNodes discharging into a ExitNode. The Render Engine Components as such are //stateless// themselfs; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations.
+<pre>The Render Engine only carries out the low-level and performance critical tasks. All configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of ProcessingNodes discharging into a ExitNode. The Render Engine Components as such are //stateless// themselves; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations.
 
 [img[Entities comprising the Render Engine|renderengine/fig6.png]]</pre>
 </div>
@@ -2024,6 +2024,9 @@ The design of Cinelerra 2 basically follows this design, but __fails because of
 
  * see also the [[Entities invoved in Rendering|RenderEntities]]</pre>
 </div>
+<div title="SideBarOptions" modifier="CehTeh" created="200706200048" changecount="1">
+<pre>&lt;&lt;search&gt;&gt;&lt;&lt;closeAll&gt;&gt;&lt;&lt;permaview&gt;&gt;&lt;&lt;newTiddler&gt;&gt;&lt;&lt;saveChanges&gt;&gt;&lt;&lt;slider chkSliderOptionsPanel OptionsPanel &quot;options »&quot; &quot;Change TiddlyWiki advanced options&quot;&gt;&gt;</pre>
+</div>
 <div title="SiteSubtitle" modifier="Ichthyostega" created="200706190044" changecount="1">
 <pre>some aspects of Cinelerra-3 design</pre>
 </div>