[Lumiera] Which timecode formats do we want?

Christian Thaeter ct at pipapo.org
Fri Jul 9 01:07:03 CEST 2010

Brian Rytel wrote:
> @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
> dialog?
> You could daisy-chain this action for all digits, rather than write a
> new widget.
> 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.

not really, input there would be very convinient. I am always think
about CAD programs and commandlines here, it would be nice when one can
enter different representation with a slightly different and convinient
syntax, whatever is currently displayed. This things need to worked out,
just some brainstorming:
  0:00:00:(00) <- I click here

12345 -> user enters a number .. jumps to the position as you described
including shift more digits into the other counters.

@123.456 go to time in sec also parse @1'2"34.5 like things as timestamp

#1234 go to a frame number

+#12 jump 12 frames forward

- at 34 jump 34 seconds backwards

well i like to have some 1 line command input someday which takes typed
commands like  "pos +#12"  "track down" and so on


> B.J.M.R.
> On Thu, Jul 8, 2010 at 1:55 PM, Brian Rytel <tesla.pictures at gmail.com
> <mailto: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 <mailto: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 <mailto: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 <mailto:Lumiera at lists.lumiera.org>
>             http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
>             http://lumiera.org/donations.html
> ------------------------------------------------------------------------
> _______________________________________________
> Lumiera mailing list
> Lumiera at lists.lumiera.org
> http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
> http://lumiera.org/donations.html

More information about the Lumiera mailing list