On Tue, Oct 9, 2012 at 5:42 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 09/10/12 23:23, Joseph Van Riper a écrit :
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/**
I'd like to know if anyone might take interest in a header library that 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