Lumiera
The new emerging NLE for GNU/Linux

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

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.