[Lumiera] Which timecode formats do we want?

Brian Rytel tesla.pictures at gmail.com
Thu Jul 8 22:53:39 CEST 2010

It should be clear that the following are separate functions and have to
handled as such:

Timestamp: The indicator (generally at the beginning) embedded into media to
align with some outside media, ie: audio, simultaneous video, or a timecode
param set for a production/project

Framestamp: similar to above but per frame. If I'm not mistaken, I have seen
these reference an absolute (clock), a relative (media file) and timecode.

Framerate: The # of frames per second.

Timecode: The constant 'time counter' for a timeline/sequence, or relevant
to an individual clip. Timecode IS NOT FRAME-RATE! While it is generally
related to frame rate, there is nothing stopping a produciton from putting
24fps footage on 30DF timecode, and it is done with some frequency (for
various reasons). This means that timecode runs essentially arbitrary to the
clips it serves. The hard part of course being that it must convert the
entered ## to display a frame from the timeline.

Example: NTSC standard-def footage is interlaced, which means you do not
have 30fps but rather 60 half-frames/second. But the TC counter counts only
to 30, in whole frame increments, while the footage is divided into
60-half-frame increments.

Typing in 00:00:1:16 into a TC widget must translate that into the courser
moving to 1 and 32/60 (because it's a 3fps TC) which actually leaves a
problem because 32/60 of a sec is only one interlaced field, so using one
deinterlace method or another the playback engine has to grab either another
field (preferred), or it has to double the current field (not preferred).
Further more, this has draw up the same fields/frames everytime the same TC
is entered.

I should note their are SMPTE standards for how to do all this.


On Thu, Jul 8, 2010 at 10:05 AM, Burkhard Plaum
<plaum at ipf.uni-stuttgart.de>wrote:

> Hi,
> Christian Thaeter schrieb:
> [...]
>  yes indeed ... this was talking about (almost) constant framerates.
>> Having a timestamp on each single frame is something different and might
>> be supported in some different way (we where thinking about this
>> before).
> Why not support them in the same way? All you need are functions for
> converting framecounts to timestamps and back.
> I basically have this in gavl like explained here:
> http://hirntier.blogspot.com/2009/09/frame-tables.html
> It's generic code which works for arbitrarily variable framerates
> and automatically reduces to trivial multiplications for constant
> framerates.
>  I actually leave this out from this discussion.
>  But more important here is, how would you represent this weird
>> non-constant framerate things in the timeline widget? shall that only
>> present frame number or absolute time and invalidate any representation
>> which depends on a well defined framerate. Or try to map that back to
>> some target framerate?
> Timeline in the GUI should of course be linear and if you zoom deep enough
> to
> see the thumbnails for single frames, they will be non-equidistant.
> Burkhard
> _______________________________________________
> Lumiera mailing list
> Lumiera at lists.lumiera.org
> http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
> http://lumiera.org/donations.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lumiera.org/pipermail/lumiera/attachments/20100708/5d436219/attachment.html>

More information about the Lumiera mailing list