[Lumiera] Which timecode formats do we want?

Burkhard Plaum plaum at ipf.uni-stuttgart.de
Thu Jul 8 15:39:39 CEST 2010


Christian Thaeter schrieb:
> 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
>     following:
>      - 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? :)

If one supports that weird stuff, one should also support variable
framerates. They are much more common than one might think.

Some media formats (flv, matroska, asf etc) don't even define a framerate.
Instead you have to use the individual timestamps. Without scanning the whole
file you won't know if the framerate is constant or not, so you must assume
that it's variable.

Even if the source framerate is constant but 30000/1001, the frame durations
in an flv file (with millisecond timestamp resolution) will alternate between
33 and 34. Without some heavy and error prone guessing you'll never find the
original framerate in the general case.

Most camera footage of course is constant framerate, but news studios (or remixers :) )
want to embed youtube downloads and cell-phone videos into their productions.

So it's IMO best to assume the worst (i.e. that constant framerate is a special case,
where all frame durations are equal).


More information about the Lumiera mailing list