[Lumiera] Which timecode formats do we want?

Burkhard Plaum plaum at ipf.uni-stuttgart.de
Thu Jul 8 13:57:32 CEST 2010


Hi,

Stefan Kangas schrieb:
> 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. 

gavl_time_t has microsecond resolution per definition. If I have a different
time scale than 1000000 (== GAVL_TIME_SCALE) I use plain int64_t instead of
gavl_time_t.

That's in my code, of course I cannot prevent people from using gavl_time_t for
other time units as well.

> 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.

Maybe one should make a distinction here:

- Timestamps: Presentation times used for synchronizing e.g. audio
   and video streams of one file. They usually start at (or near) zero

- Timecodes:  Additional (and optional) Metadata used for identifying scenes
   etc.

- Recording date/time: In some formats (DV/AVCHD/HDV) these are also stored
   in the file but usually only with second precision

Most media formats and -libraries make this distinction.

In most cases the whole timecode stuff boils down to a having one timecode
of the first frame stored somewhere in the file, because all following timecodes
are redundant. Only if timecodes are discontinuous, things get more complicated.

Burkhard


More information about the Lumiera mailing list