Boost logo

Boost :

Subject: Re: [boost] Gauging interest in time code for broadcasters...
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-09 19:01:13

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 (**
> 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.
Le 10/10/12 00:17, Joseph Van Riper a écrit :
Please don't top post on this ML.

> 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.
I don't know nothing about drop-fame codes, and I don't know how your
library take care of this specific format.

Please could you explain which kind of algorithm is needed and why at
least two frames will be off a day with the ratio approach?

> 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.
We could add some manipulators that could take care of specific formats
if the feature is widely needed.
> 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).
Could you explain why a specific ratio could not be used? Is because the
period is not a rational number?
Couldn't specific clocks help?

Is there some documentation and/or code available?


Boost list run by bdawes at, gregod at, cpdaniel at, john at