Re: [boost] Gauging interest in time code for broadcasters...

Subject: Re: [boost] Gauging interest in time code for broadcasters...
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2012-10-09 18:17:32

The library I propose would be capable of converting drop-frame timecode,
which is a little problematic for Boost.Chrono.

Boost.Chrono, if I have it right, requires a ratio.  But, to properly
express drop-frame according to SMPTE standards, one must perform a couple
of calculations in an algorithm.  If you use the ratio approach, you will
be at least 2 frames off a day for drop-frame.  That kind of accuracy might
matter to some people.  It has, at least, mattered to my company.  By
supporting those sorts of time-code formats for which a ratio does work
(and for which Boost.Chrono would work), this approach would help create a
unified interface for broadcasters working with different time code types.
 If Boost.Chrono can also support this kind of time calculation, forgive
me, as I did not notice such support in the library.

Also, I don't think Boost.Chrono parses or outputs time in a standard
timecode format.  Timecode typically looks something like hh:mm:ss:ff,
where hh represents hours, mm minutes, ss seconds, and ff frames.  The last
':' character might be a '.' or a ';' in some environments, depending upon
whether or not the time code is drop-frame, and whether or not the
application uses that kind of representation.  If I'm wrong on this point,
forgive me, as I may not have researched Boost.Chrono enough.

The library I propose would have a kind of tag for each flavor of time code
it supports, and it isn't too difficult to create other tags, so in this
way it shares some similarities with Boost.Chrono.  Specifying these tags
in the header, with proper documentation, should help make it easy for a
broadcast developer to decide upon the appropriate tag for his needs,
rather than having to know the correct ratio for Boost.Chrono (especially
where drop-frame is concerned).

- Trey

On Tue, Oct 9, 2012 at 5:42 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 09/10/12 23:23, Joseph Van Riper a écrit :
>
>  I'd like to know if anyone might take interest in a header library that
>> supports working with time code (as in, 01:00:00:00 which is 107892
>> drop-frames, or 108000 frames at 30 fps).
>>
>> The library would simply convert between frames (as a long) and
>> boost::posix_time::time_**duration types according to the kind of time
>> code,
>> and would parse or output strings according to the kind of time code.
>>  From
>> there, you'd just leverage boost::posix_time::time_**duration for any
>> calculations you need.
>>
>> I realize this is kind of a special-interest library, but the broadcasting
>> field seems so wide that something like this might be useful to quite a
>> few
>> people, so I thought I'd ask.
>>
>>
>>  Hi,
>
> I don't know if you are aware of Boost.Chrono (http://www.boost.org/doc/**
> libs/1_51_0/doc/html/chrono.**html<http://www.boost.org/doc/libs/1_51_0/doc/html/chrono.html>).
> I suspect that it share the same concerns. Please could you tell what your
> library provides in addition to Boost.Chrono?
>
> Best,
> Vicente
>
> P.S. Note that the next Boost release 1.52 contains an refactored version
> of chrono/io.
>
>
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>