Gauging interest in time code for broadcasters...
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. - Trey
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). 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.
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@wanadoo.fr> 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>
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
on Tue Oct 09 2012, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
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?
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?
http://en.wikipedia.org/wiki/SMPTE_timecode#Drop_frame_timecode explains. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Le 10/10/12 04:14, Dave Abrahams a écrit :
on Tue Oct 09 2012, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
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?
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? http://en.wikipedia.org/wiki/SMPTE_timecode#Drop_frame_timecode explains.
I was asking for the library. Thanks anyway, Vicente
It's a simple library, available here: http://www.xorbit.com/time_code.zip I also have the beginning of some documentation here (enough to at least get a feel for it): http://www.xorbit.com/boosttimecode.htm I apologize for top-posting earlier. I knew better, but forgot. Dave Abrahams has it right... drop-frame time-code cannot be expressed using ratios or rational (or even irrational) numbers with precise accuracy to the definition. The web page he linked does a good job of defining the standard, which should explain what you might see in the source code where NTSC DF is concerned. - Trey
on Tue Oct 09 2012, Joseph Van Riper <fleeb.fantastique-AT-gmail.com> wrote:
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.
It's been years since this has been relevant to my work, but in case anyone is wondering, it's a real issue. Uniform time such as that represented by chrono doesn't cover all use-cases. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
participants (3)
-
Dave Abrahams -
Joseph Van Riper -
Vicente J. Botet Escriba