[rishi02102017]

FrameTimecode.get_timecode() is documented to truncate to the requested precision when use_rounding=False. It currently formats the seconds with one extra digit and then drops it, but formatting rounds that digit, which can carry into the digits that are kept:

>>> from fractions import Fraction
>>> from scenedetect import FrameTimecode
>>> from scenedetect.common import Timecode
>>> tc = FrameTimecode(Timecode(pts=179997, time_base=Fraction(1, 90000)), Fraction(30000, 1001))
>>> tc.get_timecode(use_rounding=False)   # 1.99997s
'00:00:01.000'                            # expected '00:00:01.999'
>>> FrameTimecode(911, Fraction(24000, 1001)).get_timecode(precision=1, use_rounding=False)  # 37.996s
'00:00:37.0'                              # expected '00:00:37.9'

When the carry reaches the whole seconds it is lost, so the result can be almost a second early. This reproduces on 0.7.3 and on main.

This change truncates the value to the requested precision before it is split into hours, minutes and seconds, allowing for float error so exact frame times are not truncated down (for example, 504 frames at 23.976 fps is exactly 21.021 seconds and still prints 00:00:21.021). Output with use_rounding=True is unchanged.

• Added test_precision_truncation to tests/test_timecode.py; it fails on main and passes with this change.
• pytest, ruff check and ruff format --check pass.
• Added a changelog entry under 0.8.

[MuhammadBilalKhan267]

Thanks for catching this! #591 already fixes the same truncation bug in Timecode, and we’re planning to remove FrameTimecode in 0.8.

[rishi02102017]

Ah, makes sense, thanks. Since #591 is still a draft, would it be worth having this in 0.7.x until 0.8 is out? If not, I'm happy to close it.

[MuhammadBilalKhan267]

Unfortunately, the next planned release is 0.8. Feel free to pick up any other issues though.

[rishi02102017]

Got it, closing this then. Thanks!