58 lines
3.6 KiB
Text
58 lines
3.6 KiB
Text
2007-08-10 early informal Developers Meeting
|
|
============================================
|
|
:Author: Ichthyostega
|
|
:Date: Feb.2008
|
|
|
|
*************
|
|
this summary of a very early Lumiera developer meeting was preserved in one of our TiddlyWikis.
|
|
Interestingly, it mentions all of the core ideas of the application.
|
|
*************
|
|
|
|
_Aug 10, 2007 in #lumiera_
|
|
|
|
[small]#_Added to the Website 1/2013_#
|
|
|
|
.Participants
|
|
* cehteh
|
|
* ichthyo
|
|
* hermanr
|
|
* raffa
|
|
|
|
|
|
.Summary of discussed ideas
|
|
- maybe let the render graph builder generate a meta language which then is _jit compiled_ for each configuration
|
|
- using smart pointers and factories for objects and _avoid unprotected use of `new` and `delete`_
|
|
- if this wont work because of cycles, we might investigate specialized garbage collectors for specific cases.
|
|
- format for frames would be likely ffmpeg or such first, finally we see what suits best.
|
|
- we have to provide coverter nodes to convert frame formats for accessing different libraries anyway (ffmpeg, v4l, gstreamer, ...)
|
|
- we need a pool of worker threads and associated APIs
|
|
- accessing frames has a _time_ (get until..), _unique frame identifier_ (see below), _policies_ (what to do when out of time, quality required,..) and _hints_ (recursive dependency, must cache, playback speed and direction, ...)
|
|
- for each sequence (configuration) each node has a number (monotonic incrementing), a generation counter (increment on each parameter change), a propagation sum (from parent nodes)
|
|
- frames are identified by their time (frame number) and node number plus generation number and propagation sum. This allows easily to find out when a frame has to be rerendered
|
|
- no difference between compositor and viewer
|
|
|
|
- viewer is just a decoder where a display window attaches
|
|
- one can have multiple of such display windows
|
|
- tracks, effects, (things which are nodes in the render graph) can add GUI components to the viewer, like masking tools, panning, overlay and other compositor things.
|
|
- in the render graph we have _attachment points_ (``exit nodes''). Display and other output can only be pulled from such exit nodes. Changing just the display or attaching it to another exit node doesn't count as change of the render graph, while reordering or reconfiguring the exit nodes themselves of course _is_ a reconfiguration.
|
|
|
|
- tracks are just containers for other nodes
|
|
|
|
- they serve a GUI representation (timeline, patchbay, viewer)
|
|
- they do the mixing of contained things
|
|
- can be recursive, the GUI represents basically a tree
|
|
- we need some ``wiring'' abstraction for the GUI to make it a real graph
|
|
|
|
- rendering frames, context between frames
|
|
|
|
- the proc layer _only queries frames_ (by identifier and timeout) the backend tries to serve the best it can do (from cache or let them render)
|
|
- each render job carries some _quality limit_ (as S/N ratio) when previewing or scratching through the project this is used to generate reasonable quality previews
|
|
- individual processing nodes can use additional state for their calculations...
|
|
|
|
* the node objects themselves should stay stateless, i.e. they shouldn't store state internally.
|
|
* they can use special _context frames_, which are provided and managed by the backend (as opaque data blocks).
|
|
* they can depend on previous state, i.e request from the backend a previous context frame, the same way as they can request previous media frames from the bakend, but there is no guarantee that the backend will satisfy this request.
|
|
* on the question who decides what to do after a cache miss, we tend to put the decision into the render node (because this seems to be the simpler approach), but still have to work out the details.
|
|
|
|
|
|
|