Official Documentation published on Lumiera website
Ichthyostega
030e9aa8a2
In the first draft version, a blocked Gate was handled by »polling« the Gate regularly by scheduling a re-invocation repeatedly into the future (by a stepping defined through ExecutionCtx::getWaitDelay()). Yet the further development of the Activity-Language indicates that the ''Notification mechanism'' is sufficient to handle all foreseeable aspects of dependency management. Consequently this ''Gate poling is no longer necessary,'' since on Notification the Gate is automatically checked and the activation impulse is immediately passed on; thus the re-scheduled check would never get an opportunity actually to trigger the Gate; such an active polling would only be necessary if the count down latch in the Gate is changed by "external forces". Moreover, the first Scheduler integration tests with TestChainLoad indicate that the rescheduled polling can create a considerable additional load when longer dependency chains miss one early prerequisite, and this additional load (albeit processed comparatively fast by the Scheduler) will be shifted along needlessly for quite some time, until all of the activities from the failed chain have passed their deadline. And what is even more concerning, these useless checks have a tendency to miss-focus the capacity management, as it seems there is much work to do in a near horizon, which in fact may not be the case altogether. Thus the Gate implementation is now *changed to just SKIP* when blocked. This helped to drastically improve the behaviour of the Scheduler immediately after start-up -- further observation indicated another adjustment: the first Tick-duty-cycle is now shortened, because (after the additional "noise" from gate-rescheduling was removed), the newly scaled-up work capacity has the tendency to focus in the time horizon directly behind the first jobs added to the timeline, which typically is now the first »Tick«. ð¡ this leads to a recommendation, to arrange the first job-planning chunk in such a way that the first actual work jobs appear in the area between 5ms and 10ms after triggering the Scheduler start-up.Scheduler¡ |
||
|---|---|---|
| admin | ||
| data | ||
| doc | ||
| po | ||
| research | ||
| src | ||
| target | ||
| tests | ||
| uml | ||
| wiki | ||
| .gitignore | ||
| AUTHORS | ||
| COPYING | ||
| DIR_INFO | ||
| INSTALL | ||
| LICENSE | ||
| README | ||
| SConstruct | ||
Lumiera -- the video NLE for Linux ==================================== Version: 0.pre.03 :Date: 11/2015 ************************************************************* Lumiera is a non-linear video editing and compositing tool. The Application will allow to edit footage in the common multimedia formats (quicktime, ogg, mkv, avi) and audio/video stream codecs (dv, mpeg1/2/4, h264 ...) Lumiera features non-destructive editing, compositing tools, a selection of effects plugins, processing in RGB, YUV and RGB-float colour models and the ability to mix media with differing sizes and framerates. Lumiera is especially well suited for large and elaborate professional editing tasks with lots of material, several scenes, nested sequences, colour grading, 3D support, full fledged sound montage and multiple edit versions prepared in parallel. NOTE: as of 11/2015, Lumiera is in early development stage; it is not usable yet. The above describes the Lumiera project vision, which will need years to implement. This preview Release installs a current development snapshot in pre-alpha stage. Visit http://Lumiera.org and join the mailing list when interested in Lumiera planning and development. **************************************************************** Lumiera pre-Alpha Versions -------------------------- **This source tree doesn't yet contain a working video editing application** + Rather, it contains the framework and technology core of the envisioned Application ``Lumiera''. See http://issues.lumiera.org/roadmap[Project roadmap] As of _11/2015_ (0.pre.03):: a lot of long standing maintennance work has been done. The Project switched to C++11 and in the end even to C++14 and Debian/Jessie as reference platform, followed by clean-up of now obsolete workarounds. On the GUI side, we largely made the transition to GTK-3, which lead to rework of our timeline widget, not finished yet. This work also spured an effort the connection and communication between Proc and the UI, which is expected to be asynchroneous. Due to the limited developer resources, work on the Engine and Player part is stalled. As of _10/2013_ (0.pre.02):: the data models have been elaborated and some significant parts of the session are finished. Work has continued with time handling, a draft of the output connection framework, a draft of the player subsystem and interfaces to the engine and processing network. Unfortunately there was a considerable slowdown and decrease in team size, yet still the code base is growing towards 90k LOC. No tangible progress regarding the GUI and the backend. As of _1/2011_ (0.pre.01):: the project has created and documented a fairly consistent design, partially coded up -- starting from the technical foundations and working up. The code base is approaching 65k LOC. Roughly half of this is test code. The Application can be installed and started to bring up a GTK GUI framework, but the GUI is very preliminary and not connected to core functionality. The video processing pipeline exists only in the blueprints. As of _2/2008_:: the project has been separated completely from ``Cinelerra'', the parent project. The Community, which at that time was largely identical to the Cinelerra-CV community, choose the new project name ``Lumiera'' through a collaborative selection and vote. The basic project infrastructure is up and running, and work on the new codebase has started. We can show nothing beyond a test suite for some time to come. As of _7/2007_:: we started with the backend and render engine draft, some example code complemented by several unit tests. There is a TiddlyWiki with detailed design considerations and developer documentation and a UML model Build Requirements ------------------ For building Lumiera, you'll need: * C99 / C++14 compiler GCC `>=4.9` or Clang `>=3.5` * Git Version management system * http://www.scons.org/[SCons build system] * http://www.boost.org/[Boost libraries] * http://gmerlin.sourceforge.net/[GAVL library] * http://nobug.pipapo.org/[NoBug library] * http://www.gtkmm.org/en/[GTKmm] * http://alsa-project.org[ALSA libasound2-dev] * http://cgit.freedesktop.org/xorg/lib/libXv[libXv] * https://wiki.gnome.org/LibRsvg[lib rSVG] * https://git.gnome.org/browse/gdl[lib GDL] See the online documentation at http://Lumiera.org/download.html Debian Package -------------- Hermann Vosseler (aka Ichthyo) maintains a *Debian* packaging of the source tree - the package definition can be pulled from `git://git.lumiera.org/debian/lumiera/` - the package can be built by `git-buildpackage`