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

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 (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.
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?

Best,
Vicente