some cleanup on the main TiddlyWiki, added latest protocol
This commit is contained in:
parent
13b2b4f7a2
commit
510456d250
3 changed files with 315 additions and 95 deletions
BIN
wiki/draw/Lumi.Architecture-1.png
Normal file
BIN
wiki/draw/Lumi.Architecture-1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.3 KiB After Width: | Height: | Size: 2.1 KiB |
410
wiki/index.html
410
wiki/index.html
|
|
@ -635,6 +635,27 @@ ColorPalette
|
|||
|
||||
SiteUrl</pre>
|
||||
</div>
|
||||
<div title="ArchitectureOverview" modifier="Ichthyostega" modified="200810151608" created="200810151553" changecount="7">
|
||||
<pre>This page intends to capture the lage picture regarding Lumiera's Architecture. This may be a moving target...
|
||||
|
||||
[img[Overview of Lumiera Architecture|draw/Lumi.Architecture-1.png][http://www.lumiera.org/gitweb?p=LUMIERA;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD]]
|
||||
|
||||
//this drawing is maintained as SVG in GIT//
|
||||
~~(click on the above image...)~~
|
||||
|
||||
!Description
|
||||
* the Application has three Layers: [[Backend|backend.html]], [[Proc-Layer|renderengine.html]] and GUI
|
||||
* the Application shall be completely functional without GUI ("headless", script-driven)
|
||||
* all IO, media data fetching, processing and bookkeeping falls within the realm of the Backend
|
||||
* all media object manipulation, deciding and configuration is the Proc Layer's job
|
||||
* extensible by plugins on all levels, highly configurable, but not totally componentized (micro kernel) architecture
|
||||
* strong separation between high-level and low-level areas of the Application
|
||||
* the user/GUI manipulates a [[high-level model|renderengine.html#HighLevelModel]] whereas rendering is based on a corresponding [[low-level model|renderengine.html#OverviewRenderEngine]]
|
||||
* stored Session (state) is comprised of high-level model, a collection of [[Assets|renderengine.html#Asset]] and accompaning configuration
|
||||
* (possibly) several storage backends, abstracted out by a common interface
|
||||
|
||||
</pre>
|
||||
</div>
|
||||
<div title="AutoTools" modifier="Ichthyostega" modified="200805200610" created="200805200609" changecount="3">
|
||||
<pre>* autotools 1.10 (as of 5/2008) &dash; Question: other versions usable too?
|
||||
* the usual procedure, in short
|
||||
|
|
@ -802,14 +823,12 @@ for __Running__</pre>
|
|||
<pre>LumieraWiki
|
||||
ShortCuts</pre>
|
||||
</div>
|
||||
<div title="DesignDocumentation" modifier="Ichthyostega" modified="200810050447" created="200706181207" tags="process policy" changecount="7">
|
||||
<div title="DesignDocumentation" modifier="CehTeh" modified="200707030409" created="200706181207" tags="process policy" changecount="6">
|
||||
<pre>* There is a [[Manifest]] explaining the vision of the Lumiera project
|
||||
* The foundation how we work together is defined in LumieraDesignProcess
|
||||
* There is a description how the git repository is set up in RepositorySetup
|
||||
* we decided to write code in GNU style, with no tabs (use spaces)
|
||||
|
||||
!basic decisions
|
||||
* TimeHandling</pre>
|
||||
</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>/***
|
||||
|
|
@ -954,9 +973,11 @@ git push git://git.pipapo.org/lumiera/mob
|
|||
|
||||
lumiera/mob is an anonymous account at pipapo.org where everyone can commit changes. </pre>
|
||||
</div>
|
||||
<div title="IRC-Transcripts" modifier="Ichthyostega" modified="200807072122" created="200708120209" tags="discuss irclog" changecount="11">
|
||||
<div title="IRC-Transcripts" modifier="Ichthyostega" modified="200810151611" created="200708120209" tags="discuss irclog" changecount="12">
|
||||
<pre>We keep a protocol or short summary of each important discussion. The summaries of the monthly developer meetings are posted to the Mailinglist and can be found on pipapo.org too
|
||||
|
||||
* [[10-08 developer meeting 10.Oct.2008|IRC_2008-10-10]]
|
||||
* [[07-08 developer meeting 6.Jul.2008|IRC_2008-07-06]]
|
||||
* [[06-08 developer meeting 5.Jun.2008|IRC_2008-06-05]]
|
||||
* [[05-08 developer meeting 8.May.2008|IRC_2008-05-08]]
|
||||
* [[04-08 developer meeting 3.Apr.2008|IRC_2008-04-03]]
|
||||
|
|
@ -968,12 +989,12 @@ lumiera/mob is an anonymous account at pipapo.org where everyone can commit chan
|
|||
* [[buffer allocation for render nodes (6/08)|IRC_log_BufferAllocation_2008-06]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="IRC_2007-08-10" modifier="Ichthyostega" created="200802021815" tags="irclog" changecount="1">
|
||||
<div title="IRC_2007-08-10" modifier="Ichthyostega" modified="200810140236" created="200802021815" tags="irclog" changecount="2">
|
||||
<pre>!10/11 aug 2007
|
||||
* 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 diffrent libraries anyway (ffmpeg, v4l, gstreamer, ...)
|
||||
* we need a pool of worker threads and associated api's
|
||||
* 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
|
||||
|
|
@ -981,20 +1002,20 @@ lumiera/mob is an anonymous account at pipapo.org where everyone can commit chan
|
|||
** 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 ''attachement points'' i.e. ~ExitNode-instances. Display and other output can only be pulled from such ~ExitNodes. Changing just the display or attaching it to another ~ExitNode doesn't count as change of the render graph, while reordering or reconfiguring the ~ExitNodes themselfes of course //is// a reconfig.
|
||||
** in the render graph we have ''attachment points'' i.e. ~ExitNode-instances. Display and other output can only be pulled from such ~ExitNodes. Changing just the display or attaching it to another ~ExitNode doesn't count as change of the render graph, while reordering or reconfiguring the ~ExitNodes themselves of course //is// a reconfiguration.
|
||||
* tracks are just containers for other nodes
|
||||
** they serve a gui representation (timeline, patchbay, viewer)
|
||||
** 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 'wireing' abstraction for the gui to make it a real graph
|
||||
** 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 processings...
|
||||
*** the node objects themselfs should stay stateles, i.e. they shouldn't store state internally.
|
||||
** 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 aproach), but still have to work out the details.
|
||||
* 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.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="IRC_2008-02-01" modifier="Ichthyostega" modified="200802031846" created="200802021821" tags="irclog" changecount="28">
|
||||
|
|
@ -1673,6 +1694,272 @@ While in this discussion, several aspects of the cooperation of GUI and Proc lay
|
|||
Next meeting: ''Thursday 3.July 2008 16:30 UTC''
|
||||
</pre>
|
||||
</div>
|
||||
<div title="IRC_2008-07-06" modifier="Ichthyostega" created="200810151616" tags="irclog excludeMissing" changecount="1">
|
||||
<pre>! 6.July 2008 on #lumiera
|
||||
__Participants__
|
||||
* ichthyo
|
||||
* cehteh
|
||||
* jilt
|
||||
* dmj726
|
||||
* Teld
|
||||
* _nasa_
|
||||
* alcarinque_
|
||||
* MNO
|
||||
* Wescotte
|
||||
* weatherhead
|
||||
|
||||
//Protocol written by Teld//
|
||||
|
||||
!Boilerplate
|
||||
!!Organization of this meeting
|
||||
* dmj726 intends to write the protocol
|
||||
* ichtyo is chairman
|
||||
* there is no agenda, so this is a freeform meeting
|
||||
!!Leftovers from last meeting
|
||||
//There are no leftovers//
|
||||
|
||||
!Introduction of Lumiera
|
||||
Because there are quite some new participants, an introduction of the project Lumiera is given
|
||||
|
||||
There are 3 core devs:
|
||||
* cehteh: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git
|
||||
* ichthyo: proc layer, render graph, in the middle, C++, he maintains scons
|
||||
* joelholdsworth: GUI in C++/Gtkm
|
||||
Other people involved:
|
||||
* rcbarnes: ui designer and HCI expert
|
||||
* raffa: web content
|
||||
* Simav: gives a hand when and where he can
|
||||
* Teld: web infrastructure
|
||||
|
||||
The foundations of the design are already done but a lot of detail needs to be worked out. cehteh and ichtyo provide a non exhaustive list.
|
||||
|
||||
cehteh:
|
||||
* improvement of the testsuite (simple Bash)
|
||||
* start of a worker thread manager (Posix knowledge required)
|
||||
* start of the scheduler (some Posix, good C coding)
|
||||
* runtime profiler (little but advanced Posix realtime programming job)
|
||||
* review of code and documentation
|
||||
* system administration
|
||||
* setup of a build/test environment on the server
|
||||
* setup and maintain postfix/dovecot by a mail administrator
|
||||
ichtyo:
|
||||
* asset management (keeping track of all media files, captures, clips, scenes)
|
||||
* session loading saving and the issues of compound documents
|
||||
* session structure related issues to be able to Import/Export/Connect via e.g. OSC (Open Sound Control) or JACK
|
||||
* flesh out the more high level "edit operations" and the interface to UNDO
|
||||
* Prolog integration after the first integration round has been reached. The Prolog interpreter will do some of the more advanced configuration (example: if effect XYZ is used, then deinterlace beforehand).
|
||||
* integration with some sort of production support software (like Celtx)
|
||||
cehteh emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit as long as he communicates and acknowledges with the persons involved. ichtyo points out that the plugin structure is very important: anything that is not legally completely clean (proprietary), should be factored out into a sister project and be loaded as plugin.
|
||||
|
||||
!Issues and questions that come up
|
||||
!!handling of config errors.
|
||||
When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane. Therefore, the config system will be built to log a warning and the user code does not need to care. The user just gets an alert and the application continues to work.
|
||||
|
||||
!!scripting language.
|
||||
There will be a scripting interface. ichtyo does not want scripts everywhere, only at well defined interfaces. That implies also that scripts cannot just do anything, only that what is permitted in a controlled way. The meeting agrees on that. cehteh wants one default language and proposes Lua: light, simple.
|
||||
|
||||
Other members suggestions: Python, Ruby, Scheme. However, Python and Ruby are very slow. Scheme has many variants.
|
||||
|
||||
!!editing on small devices (eeePC)
|
||||
Problem: video editors GUIs are some of the most elaborate and complicated GUIs. However, basic functions consist of only a few buttons. Proxy editing could be a solution. It is decided that it is not a primary goal now. First the basics have to be implemented.
|
||||
|
||||
!!uWiki.
|
||||
uWiki is the glue between a markup driver (Asciidoc) and revision control (git). Haserl with Bash is used now. Haserl appears to have problems with conditional includes. Its limits have been reached while prototyping. Lua could very well be a valid replacement. It will be investigated. PHP is rejected because it is not stable and suffers from serious security problems.
|
||||
|
||||
!!'musical' timeline in bars and beats
|
||||
The questions of syncing and linking things together are already on the core agenda: the so-called placement concept. Discussion is still going on, especially with the GUI developer joelholdsworth. See for detailed information: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor
|
||||
|
||||
!Next meeting
|
||||
The next meeting will be held ''Thursday, 7 August 19:00 UTC''
|
||||
</pre>
|
||||
</div>
|
||||
<div title="IRC_2008-10-10" modifier="Ichthyostega" modified="200810151623" created="200810151617" tags="irclog excludeMissing" changecount="6">
|
||||
<pre>!Oct 10, 2008 on #lumiera
|
||||
19:00 - 23:15 UTC
|
||||
__Participants__
|
||||
* cehteh
|
||||
* ichthyo
|
||||
* joelholdsworth
|
||||
* alcarinque
|
||||
* ~KenSentMe
|
||||
* Plouj
|
||||
* raffa
|
||||
* thorwil
|
||||
* Victor_Sigma
|
||||
* wildhostile
|
||||
|
||||
//Protocol written by Ichthyo//
|
||||
|
||||
!!!organisational
|
||||
Not much of a fixed agenda this time.
|
||||
Agreement to start with the Logo discussion, as this is of general interest, followed by the design drafts and similar dev topics.
|
||||
|
||||
!The Lumiera Logo
|
||||
Summary of the situation: discussion regarding a logo for Lumiera is going on sporadically since quite some time. Several people from the community have made proposals. Also, there was discussion about the criteria a logo would have to fulfil. Especially the core devs raised the bar and required quite some professional level of design. On the contrary, several members of the community were concerned that such a demanding attitude will hinder creativity in a domain which is far off from coding. Moreover, many people complained they are really excited about Lumiera and strongly want to participate in some manner, but find it very difficult in the current phase of the project to give any valuable contribution.
|
||||
|
||||
This summer, one of the proposals by [[Leandro Ribeiro|http://farm4.static.flickr.com/3060/2927333034_ac94be80ea_b.jpg]] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and [[explained|http://www.pipapo.org/pipawiki/JoelHoldsworth/LogoThoughts]] his reservation. Prior to this meeting some people joined a brainstorming session and came up with [[another design|http://www.pipapo.org/pipawiki/Lumiera/Logos?action=AttachFile&do=get&target=combo.png]] compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users.
|
||||
|
||||
Thus, while basically it would be possible for the core devs to shorten the process by just picking a design which is acceptable for all, maybe after augmenting it a little, several of the arguments articulated this far are in favour of a more formal decision by a contest:
|
||||
* it would allow for a lot of people to really participate
|
||||
* it could help to shape a general (graphic) style for Lumiera
|
||||
* it could underpin the fact Lumiera indeed is a collaborative effort
|
||||
* it doesn't mean additional work for the core devs on the whole
|
||||
* it helps spreading the word
|
||||
|
||||
Then, there is some discussion about the requirements. The core devs are concerned to keep up some quality level, because there is the possibility for the community to embrace a design, but when Lumiera enters the area it is intended to do, the standards of comparison will be different. The GIMP logo can be quoted as a negative example here.
|
||||
|
||||
!!Conclusion
|
||||
There will be a Lumiera Logo contest.
|
||||
* we should further discuss requirements on the Mailinglist until the end of the next week
|
||||
* the ''deadline for submissions'' will be the next meeting (Nov 12 2008)
|
||||
* then, after a pre-selection phase, the vote shall be conducted prior to the December meeting.
|
||||
|
||||
Some minimal technical requirements will be enforced:
|
||||
* the basic sign fits a compact rather quadratic bounding box (like 4:3)
|
||||
* easy to print on various media (on posters, t-shirts, ..)
|
||||
* basically a shape, using only a small number of solid colours (web safe)
|
||||
* should work on different backgrounds, esp. not requiring white background
|
||||
* the design should scale from microscopic size (favicon) up to big posters
|
||||
* vector graphic source is mandatory
|
||||
|
||||
Besides, we give some artistic guidelines
|
||||
* it should be recognisable
|
||||
* it should contain something like a sign, not just "Lumiera" in a fancy font
|
||||
* it should not rely on transparencies, gradients and subtle shades,
|
||||
* it should be viable, possibly work well in different presentation styles, able to be simplified as well as graphically augmented
|
||||
|
||||
Raffa volunteers to help organizing the contest and the voting.
|
||||
----
|
||||
|
||||
|
||||
|
||||
|
||||
!Recurring Topics: design proposals
|
||||
Discussion of open [[design process|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess]] drafts.
|
||||
|
||||
!!Mistakes to avoid
|
||||
[http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid Mistakes to avoid in the Lumiera Design]
|
||||
We are carrying this one along since quite some time and we'd like to get rid of it, either by reworking it or by dropping it as-is. Because it contains a mixture of things
|
||||
* we fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic here. We are aware of the recurring problems with open source video editing. That's why we are here.
|
||||
* the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to prove these statements.
|
||||
|
||||
While it is certainly //desirable// to be cross-platform as much as possible and especially ''target Microsoft Windows'', we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform.
|
||||
|
||||
While it is certainly //desirable// to make the application as robust as possible, we don't see how ''using multiple separate processes'' could help us with this goal //without creating major scalability or performance problems// due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner.
|
||||
|
||||
__Conclusion__: drop it
|
||||
|
||||
!!!!on the question of separate processes
|
||||
The only practical solution would be to separate the GUI. Separating backend and proc-layer doesn't make much sense, technically speaking. We re-considered this question. Joelholdsworth (GUI) and Ichthyo (Proc-layer)prefer running the GUI in-process and to avoid the additional hassle with shared memory. Cehteh (backend) doesn't care for know and would like to re-discuss it as an option later on. This is somewhat similar to the possibility of running Lumiera distributed over the network, which is a goal, but not an immediate one.
|
||||
|
||||
|
||||
!!Tag Clouds
|
||||
[http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TagCloudsOnResources Tag clouds on resources]
|
||||
Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DelectusShotEvaluator "Delectus"]
|
||||
|
||||
__Conclusion__: drop it
|
||||
|
||||
|
||||
|
||||
!!Overview of Lumiera Architecture
|
||||
[http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview Architecture Overview]
|
||||
The purpose of this drawing to give an first impression what subsystem is where and what the names mean. Since discussed last time, Ichthyo re-arranged the plugins as requested and added some details for the backend. Joelholdsworth points out that it's OK for him to show the GUI just as a single block here (and of course the GUI has much more internal structure). Cehteh adds that maintaining this drawing surely is a moving target, so we better remove the rendered image and just retain the textual description and link to the source (SVG), which is in GIT.
|
||||
|
||||
__Conclusion__: accept it, change the image to a link
|
||||
|
||||
|
||||
|
||||
!!EDLs as Meta-Clips
|
||||
[http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/EDLsAreMetaClips EDLs are meta-clips]
|
||||
This is just a high-level proposal, which doesn't go into technical details of implementing nested EDLs. It just poses the question "do we want to treat nested EDLs as being meta-clip" -- which we do.
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
|
||||
|
||||
!!The Builder
|
||||
[http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcBuilder Builder in the Proc-Layer]
|
||||
Similar to the previous one, this is a high-level proposal. It covers the fundamental approach Ichthyo takes within the Proc-Layer. Cehteh adds that he agrees to 98% and the remaining 2% are just matter of favour. Personally, he would have preferred one large graph which gets garbage collected (instead of the segmented graph)
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
|
||||
|
||||
!!High-level Model
|
||||
[http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcHighLevelModel Overview of the High-level model within the Proc-Layer]
|
||||
Cehteh queries if this shouldn't be better moved over to the documentation? He is fine with the contents, but it seems to be a bit voluminous for a design proposal. Ichthyo asks to leave it there just for now, as he feels it still needs review.
|
||||
|
||||
__Conclusion__: leave it for now, maybe retract it from the design proposals and file it as documentation?
|
||||
|
||||
|
||||
|
||||
!!Lua scripting language
|
||||
[http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ScriptingLanguage use Lua as required scripting language]
|
||||
All core devs agree with this decision. Joelholdsworth points out that he is fine with Lua, just he didn't want to write the GUI in it. Ichthyo adds that Lua is probably the best choice from today's mainstream scripting languages, because it is very lightweight. He further points out, that having Lua as //required// scripting language doesn't rule out using other popular languages (Python, Ruby) for scripting. Just they aren't required for running Lumiera. Cehteh will have a look at the details as soon as possible, but has currently other more urgent things in the queue. (Plouj shows interest to help here)
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
|
||||
|
||||
!!Time Handling
|
||||
[http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling time handling]
|
||||
A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done //on demand.// Joelholdsworth sais sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time.
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
Note: the proposed rigid testsuite for time handling is necessary only when we introduce a wrapper...
|
||||
|
||||
!!Interface naming convention
|
||||
See the design proposal [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/InterfaceNamespaces Interface Namespaces]. While working on the plugin loader, ''Cehteh'' and ''nasa'' did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry.
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
----
|
||||
general Topics
|
||||
|
||||
!Config System
|
||||
''cehteh'' landed the first version of this subsystem and asked for review and testing. Currently it's "work with no progress", but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type).
|
||||
|
||||
|
||||
!Use of Namespaces
|
||||
Currently there is no clear uniform rule regarding namespaces use. ''Joelholdsworth'' places his code within lumiera::gui and below. He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies and all of Lumiera should comply and put anything below a lumiera:: root. On the contrary, ''Ichthyo'' deliberately moved his implementation code away from the central lumiera:: interface hierarchy into shallow namespaces and avoids nesting. He argues that having all code below luimiera:: effectively makes this namespace global or forces it to be void of any function; rather he'd prefer to import every interface explicitly into the implementation namespace. ''Cehteh'' argues that having a global lumiera::, even if empty, would mark a general claim and stand for the uniformity of the project. Generally, there should be some correspondence between folders and namespaces.
|
||||
|
||||
No conclusion yet, to be discussed further.
|
||||
|
||||
|
||||
!Interface Definition Language
|
||||
In his work on the plugin loader, ''Cehteh'' created a first draft how to export an interface, and calls for review. An example can be found in [http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=tests/backend/test-interfaces.c;h=fb1c4d30a34414767a313d24df60e679c96ad2a7;hb=7323114e77348995ccaf03417136aef7ee332776 tests/backend/test-interfaces.c]
|
||||
|
||||
An interface is a list of "slots" mapping functions. The interface descriptor is itself realised as interface, an thus can be versioned, extended and specialised. By use of some glue code and macros we create a simple Interface Definition Language
|
||||
* after exporting a header with the C interface, including the types to be used...
|
||||
* LUMIERA_INTERFACE_DECLARE creates an interface description (i.e. the official interface)
|
||||
* implementing such an interface can be done in 3 major ways
|
||||
* LUMIERA_INTERFACE_INSTANCE creates an instance on-the-fly (e.g. for descriptors)
|
||||
* LUMIERA_EXPORT for defining a table of functions/interfaces to export from the core
|
||||
* LUMIERA_PLUGIN for defining an interface table for functions located within a dynlib module (plugin)
|
||||
* besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps onto an existing function directly
|
||||
|
||||
The plugin loading system cares for mapping the given implementation function to the interface slots. Interfaces from the core need to be registered before they can be used, while for plugins this is done automatically on loading the module. The client code later just calls {{{interface_open()}}} and {{{interface_close()}}} where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader, registry and/or plugin-DB shall manage it transparently.
|
||||
|
||||
Version numbering starts with 1 and uses minor version numbers for compatible changes and major version numbers for everything that breaks existing asumptions. Version number zero is reserved for experimental work and per definition always the most recent version number.
|
||||
|
||||
The system is designed to be very flexible and extensible, but this foundation really needs thorough review.
|
||||
|
||||
Joelholdworth expresses some concern regarding the UIDs in octal notation used within the interface description. Cehteh explains they never need to be specified by client code. They are just distinctive IDs and provided for some special case within the plugin loader / serializer. He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring. The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code.
|
||||
|
||||
!!Conclusion
|
||||
|
||||
looks good, agreement by all core devs.
|
||||
Should be reviewed and investigated in detail to find any hidden problems.
|
||||
|
||||
|
||||
!Next meeting
|
||||
|
||||
There were some problems with the meeting schedule. Using the first week of month seems to be problematic. We'll try with second wednesday...
|
||||
|
||||
The next meeting is scheduled for ''Wednesday Nov 12 2008 19:30 UTC'' at #lumiera
|
||||
</pre>
|
||||
</div>
|
||||
<div title="IRC_log_BufferAllocation_2008-06" modifier="Ichthyostega" created="200806211624" tags="irclog excludeMissing" changecount="1">
|
||||
<pre>! 5.June 2008 on #lumiera
|
||||
__cehteh__ and __ichthyo__
|
||||
|
|
@ -2152,23 +2439,26 @@ This distributed wiki might be used instead the pipapo.org wiki, investigate tha
|
|||
Wiki works. It is simple to use and just flexible enough to handle the task. I don't go to install any other software for such tasks on my server. While the design progresses I'd propose to move our work into git repositories and eventually phase this wiki pages out anyways. I'd rather like to start out distributed/git right away .. but git gives us only a fine storage layer, for a design process we need some good presentation layer (later when using git and starting the implementation everyones favorite editor serves for that) I have no better ideas yet to solve the presentation problem other than using this wiki (or maybe Bouml).
|
||||
</pre>
|
||||
</div>
|
||||
<div title="LumieraWiki" modifier="Ichthyostega" modified="200808280150" created="200706172308" tags="portal" changecount="41">
|
||||
<div title="LumieraWiki" modifier="Ichthyostega" modified="200810151550" created="200706172308" tags="portal" changecount="46">
|
||||
<pre>[<img[draw/LumiLogo.png]]
|
||||
|
||||
|
||||
|
||||
|
||||
''Lumiera'' is the emerging professional non linear video editor for Linux
|
||||
|
||||
This is the entry point to several [[TiddlyWiki]]-Pages containing the developer and design documentation.
|
||||
|
||||
This is the entry point to several [[TiddlyWiki]]-Pages containing the developer and design documentation. The documentation is split in several parts corresponding to the parts of the application. Those TiddlyWiki pages are self modifying HTML pages; we include them into the GIT source tree. For the future we plan to move the contents of these developer doc wikis into a GIT backed uWiki (still under development as of 10/2008)
|
||||
* we maintain (semi-) final design docs in DesignDocumentation
|
||||
* Things get often worked out on IRC, see IRC-Transcripts for decisions made there and not yet put into the proper documentation places
|
||||
* Things get often worked out on IRC, see IRC-Transcripts for protocols, transcripts and decisions made there
|
||||
|
||||
----
|
||||
!Architecture and Subsystems
|
||||
to get started, we create design drafts emphasizing different aspects and regions of Lumiera
|
||||
&rarr; see the ArchitectureOverview
|
||||
|
||||
* Cehteh works on the data backend, see [[this page|backend.html]]
|
||||
* Ichthyo focuses mainly on Edit operations and Builder, [[see this separate page|renderengine.html]]
|
||||
* Joel started with a GUI implementation based on GTK
|
||||
* Joel builds the Lumiera GUI based on GTK
|
||||
* Gmerlin is in charge of [[GAVL|http://gmerlin.sourceforge.net/gavl.html]] for processing of video data
|
||||
* Some tools which don't fit somewhere else and are used everywhere are put into a [[Support Library|support_library.html]]
|
||||
|
||||
|
|
@ -3209,10 +3499,11 @@ Typically, one would just write the necessary definitions as they come into one
|
|||
Moreover, one could simply list all needed files or break everything down into a hierarchical build. But instead, we use for most objects a helper function (located in {{{admin/scons/Buildhelper.py}}}) called {{{srcSubtree()}}}, which will scan a directory tree and add all {{{'*.c','*.cpp','*.cc'}}} - files as Object nodes to the build process. Besides that, we use the //hierarchical aproach rather reluctant//: at the moment, only the subtree for separate tools and the tests-directory have a separate buildscript. Probably, the subtree for plugins will get one as well at some point in the future.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ShortCuts" modifier="MichaelPloujnikov" modified="200706270305" created="200706260438" tags="portal" changecount="7">
|
||||
<div title="ShortCuts" modifier="Ichthyostega" modified="200810151609" created="200706260438" tags="portal" changecount="8">
|
||||
<pre>~~This small Tiddler contains usefull Shortcuts, Info, Links~~
|
||||
|
||||
*[[Wiki-Markup|http://tiddlywiki.com/#MainFeatures]]
|
||||
*[[Wiki-Markup|http://tiddlywiki.org/wiki/TiddlyWiki_Markup]]
|
||||
*[[Design-Process|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess]]
|
||||
*
|
||||
----
|
||||
</pre>
|
||||
|
|
@ -4597,82 +4888,11 @@ function addKeyDownHandlers(e)
|
|||
}
|
||||
//}}}</pre>
|
||||
</div>
|
||||
<div title="TiddlyWiki" modifier="Ichthyostega" modified="200708120058" created="200706260506" tags="excludeMissing" changecount="4">
|
||||
<div title="TiddlyWiki" modifier="Ichthyostega" modified="200810151552" created="200706260506" tags="excludeMissing" changecount="5">
|
||||
<pre>The Name of the Software driving this Wiki. Is is written completely in ~JavaScript and contained in one single HTML page.
|
||||
Thus no server and no network connection is needed. Simply open the file in your browser and save changes locally. As the wiki HTML is located in the Lumiera source tree, all changes will be managed and distributed via [[GIT|GitNotes]]. While doing so, you sometimes will have to merge conflicing changes manually in the HTML source. There is a 'empty.html' in the same folder serving as template for generating new wikis. Please refrain from editing it.
|
||||
* see GettingStarted
|
||||
* see [[Homepage|http://tiddlywiki.com]], [[Wiki-Markup|http://tiddlywiki.com/#MainFeatures]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="TimeHandling" modifier="Ichthyostega" modified="200810050506" created="200810050456" changecount="8">
|
||||
<pre>/%||'''State'''||''Final''||%/
|
||||
||'''State'''||''Draft''||
|
||||
||'''Date'''||[[Date(2007-06-21T05:12:03Z)]]||
|
||||
||'''Proprosed by'''||["Ichthyostega"]||
|
||||
|
||||
!time handling
|
||||
how to handle time values in the code and which policy to aply to the "current" position
|
||||
|
||||
!!Description
|
||||
# Representation of time values
|
||||
#* we use an uniform time type. Time is time, not frames, samples etc.
|
||||
#* all timings in Lumiera are based on integral datatypes
|
||||
#* we use a fixed, very fine grid, something of the sort of microseconds
|
||||
#* the internal representation is based on a {{{typedef int64_t gavl_time_t}}}
|
||||
#* we use a set of library routines and convenience-methods to
|
||||
#** get time in different formats (fractional seconds, frame counts)
|
||||
#** calculate with time values (overloaded operators)
|
||||
#* time measurement is zero based (of course :-P )
|
||||
# Quantizing to a frame index or similar
|
||||
#* quantizing/rounding shall happen only once at a defined point in the calculation chain and, if in doubt, be done always as late as possible.
|
||||
#* values needing to be quantized to time (grid) positions are calculated by half-way rounding, but the result should not depend on the actual zero-point of the scale (i.e. {{{floor(0.5+val)}}}, thus quant(0.5) yields 1, quant(0.49) yields 0, quant(-0.5) yields 0 )
|
||||
# Position of frames[>img[draw/FramePositions1.png]]
|
||||
#* frame numbers are zero based and Frame 0 starts at time=0 (or whatever the nominal start time is)
|
||||
#* each frame starts when the locator hits its lower border (inclusively) and ends when the locator is on its upper border (exclusively)
|
||||
#** when the locator snaps to frames this means it can be placed on the start positions of the frames solely
|
||||
#** when the locator is placed on such a start position, this means //always// displaying the frame starting at this position, irrespective of playback direction.
|
||||
# Current position for keyframe nodes and automation[>img[draw/FramePositions2.png]]
|
||||
#* when parameter values for plugins/automation need to be retrieved on a per frame base (which normally is the case), for each frame there is a well defined __//point of evalutation//__ time position, irrespective of the playback direction
|
||||
#* there is no single best choice where to put this "POE", thus we provide a switch
|
||||
#** //point of evalutation// of the automation is in the middle of the timespan covered by a frame
|
||||
#** //point of evalutation// is on the lower bound of each frame
|
||||
#** maybe additional position or fraction (?)
|
||||
#* moreover, we provide an option to snap the keyframe nodes to the //point of evalutation// within each frame or to be able to move them arbitrarily
|
||||
#* when keyframes are set by tweaking of parameters, they are located at the //point of evalutation// position.
|
||||
|
||||
|
||||
!!!!Tasks
|
||||
* figure out what has to be done when switching the "current position" policy on a existing project
|
||||
|
||||
|
||||
!!!Alternatives
|
||||
Leave everything as in Cinelerra2, i.e. show frames after the locator has passed over them, behave differnt when playing backwards and set the keyframes on the position of the locator but use them on the frame actually to be shown (which differs according to the playback direction but is always "one off").
|
||||
|
||||
Why not? because it makes frame-precise working with keyframes a real pain and even creates contradictory situations when you
|
||||
switch back and forward while tweaking.
|
||||
|
||||
Similar for the issues with quantized values. At first sight, e.g. directly using the frame numbers as coordinates (as Cinelerra does) seems to be clever, but on the long run we get lots of case distinctions scattered all over the code. Thus better use one uniform scheme and work with precise time values as long as possible and only quantize for rendering a given frame.
|
||||
|
||||
|
||||
!!Rationale
|
||||
The intention is to make time handling and calculations as uniform and "rational" as possible. We try to stick to the precise mathematical values and let the calculations just yield an result in an uniform manner, instead of sticking to "simple" values like frame counts or even a session-wide frame rate
|
||||
# time and interval calculations are tricky. Solve this question once and be done.
|
||||
# rounding is always dangerous, rounded values are not the more "clean" values. The floor-rounding rule is chosen, because the length of an interval after quantizion should not depend on the position in relation to the zero point. The usual mathematical rounding behaves "symmetrical" to the zero point, which could yield a different length after quantizion if an interval contains the zero point
|
||||
# this is based on the analoy with real film running through a film projector (or the usual fencepost problem)
|
||||
# while using the actual position of the locator as the "current" position for keyframes seems more natural at first, it crates problems when mixing footage with different framerate or when using a low-framerate proxy footage
|
||||
|
||||
|
||||
|
||||
!Comments
|
||||
This is the summary of a discussion cehteh, Plouj and ichthyo just had on irc.
|
||||
-- ["Ichthyostega"] //2007-06-21T05:12:03Z//
|
||||
|
||||
We use Gavl now
|
||||
-- ["ct"] //2008-03-05T16:19:22Z//
|
||||
|
||||
I've tidied up this old design proposal, we could make it final now. I've changed the rounding rule, please check if it's OK. In the original proposal, we wanted to use the common mathematical rounding rule, i.e. round(-x) = - round(x) . I changed this, because of the danger of interval lengts or alignment to "jump" dependant on the position in relation to the time zero point.
|
||||
-- ["Ichthyostega"] //2008-10-04T22:47:54Z//
|
||||
|
||||
* see [[Homepage|http://tiddlywiki.com]], [[Wiki-Markup|http://tiddlywiki.org/wiki/TiddlyWiki_Markup]]
|
||||
</pre>
|
||||
</div>
|
||||
<div title="whatInBOUML" modifier="Ichthyostega" modified="200708051535" created="200706260559" tags="discuss policy" changecount="3">
|
||||
|
|
|
|||
Loading…
Reference in a new issue