[Lumiera] Which timecode formats do we want?

Brian Rytel tesla.pictures at gmail.com
Thu Jul 8 23:16:39 CEST 2010

@Stefan, just checked ardour

Having to click to TC widget 4 times to enter a TC location is maddening. Is
there a way to have it take all the numbers entered and simply move them
"over" to the next highest field?

My non-programmers concept:

00:00:00:(00) <- I click here
and input 1004
the input dialog knows only (2) digits per dialog (as it does now),
but rather than limiting further entry, it would pass (10) to the next
You could daisy-chain this action for all digits, rather than write a new

I don't know how easy/logical that is in code, let me know...I should also
note my described method is a convention in all professional NLEs, and
should be considered carefully.

While I don't intend to contradict any current design concepts, CT described
the TC widget as primarily a display.
In use, the TC counter(s) (as there are generally several) are there equally
for entry & display, and have to effectively do both.


On Thu, Jul 8, 2010 at 1:55 PM, Brian Rytel <tesla.pictures at gmail.com>wrote:

> My above post is the "software-independent" way of describing this.
> However, none of this is all that directly related to the widget, which is
> a front-end.
> I need to pop open ardour to see it's TC handling, give me a second.
> B.J.M.R.
> On Thu, Jul 8, 2010 at 1:53 PM, Brian Rytel <tesla.pictures at gmail.com>wrote:
>> 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.
>> B.J.M.R.
>> 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/a9684394/attachment.html>

More information about the Lumiera mailing list