[Lumiera] Timeline, Timecode-widget and "Quantisation framework"

Ichthyostega prg at ichthyostega.de
Thu Oct 20 15:56:53 CEST 2011

>> ... somewhere in the *session* the TimeGrid is built. Probably when we 
>> create the model element for the timeline and connect it to some output 
>> running with 25fps. If we'd reconnect to another output running with
>> 30fps, than the grid would be redefined or changed.

Am 20.10.2011 06:41, schrieb Michael R Fisher:
> ...  When you say 'the model' do you mean a gui proxy model or something in 
> the backend?

Sorry for not being explicit enough. I mean the model in the
Session, which resides in "Proc-Layer" i.e. the middle layer.

The key point here is that Lumiera won't use a session wide
fixed frame rate. Many other existing applications go that
route, which requires the user to choose a fixed "standard
frame rate" for a new project -- which turns out to be difficult
to change after-the fact.

We choose a different approach here: we don't base the editing
on a "time code", but on absolute time values. (actually we
use "micro ticks" of 1 microsecond length, which can be represented
as a single 64bit long integer value). This turns the timecode or
frame count into something generated on-the-fly, either as format
for presentation, or during playback.

In the way it's currently planned and implemented, the
*output configuration* will be the key element for establishing
the currently used frame rate. Each timeline has a fixed output
configuration, which is stored in the model. This output configuration
defines a number of ports, each with a specific "media stream type".

In the typical standard setup, this will be a (mono) video port and a
stereo audio port. Thus, the "media stream type" for video will tell
us: one channel, XX frames per second, and e.g. YUV colourspace.
The audio "stream type" will tell us: two channels 48kHz sampling rate,
16bit linear PCM using integer little-endian samples, or the like.

For Playback and Rendering, we need an output-connection, and from
there, we get the media stream parameters. This establishes the
frame grid to use.

Now, such an highly dynamic approach is potentially dangerous. Basically,
we need to do these "quantisation calculations" (i.e. finding out the frame
number for a given absolute time value) in an absolutely reproducible way.
This is perfectly feasible, because we're using integer arithmetic. And
we strive to do the "rounding" (the quantisation to frames) through a
fixed set of library routines solely.

Hopefully this makes the rationale somewhat more clear


More information about the Lumiera mailing list