[Lumiera] Which timecode formats do we want?

Brian Rytel tesla.pictures at gmail.com
Thu Jul 8 22:55:38 CEST 2010


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/57d5e8f2/attachment.htm>


More information about the Lumiera mailing list