[Lumiera] Which timecode formats do we want?

Christian Thaeter ct at pipapo.org
Thu Jul 8 15:11:02 CEST 2010

Stefan Kangas wrote:
> Burkhard Plaum <plaum at ipf.uni-stuttgart.de> writes:
>> If I'm not mistaken, all timecode formats can losslessly and trivially
>> be converted from/to framecounts, right? So would it make sense to support
>> anything but framecounts internally?
> Internally, time is represented by gavl_time_t, which is a 64 bit
> integer.  You can think of it as milliseconds based, though it can be
> much more precise if needed.  My understanding is that the decision has
> been made to have time continous, instead of frame based.[1]
> All timecode formats I have looked at thus far can be losslessy
> convertable to/from this representation without much hassle.

I try to explain the full story for the non-programmer here a bit

Indeed as Burkhard saied frame numbers are the base internaly, these
will be mapped to gavl_time_t roughly with the following equation:

  time = frame * framerate * devitation

So lets look at this things

 * 'time' is the gavl_time_t which has a microsecond precision
 * 'frame' is the frame number, contingous incrementing
 * 'framerate' is a rational (60000/1001 for NTSC for example) and NOT a
   float. The framerate is part of the footages metadata.
 * 'dervitation' is some correction value which is the product of the
     - one factor global per project (possibly always 1.0)
     - one factor per reel (footage)
     - down to a per-frame correction (anyone still glues)
     - possible other sources, like automation, remember this cheap
       consumer cameras which drift in speed when they get warm?
       you possibly even can add correction for handcranked film here,
       did anyone saied Laterna Magica? :)

But back to Stefans questions, People have to understand that how
Lumiera handles things internally and how these are represented in the
GUI are quite different things.

Stefan here asked what formats need to be presented to the user, this
included simple formatting as in "do you want to see 0:00:00.11 or
1'2"34 or what format" this is just the visual representation.

Next comes what needs to be implemented to map the internal time format
to the desired presentation format, this includes nasty things like
drop-frame and other conversions.

I think ultimately this boils down to "Do we want to provide a hardcoded
set of about half a dozen time formats, or do we discover that people
need way more formats and we have to implement something more generic?"


More information about the Lumiera mailing list