Releases: eoyilmaz/timecode
1.5.1
1.5.0
What's Changed
- Added support for Python 3.13 and 3.14 and dropped support for Python 3.8.
- Support SMPTE ST12-3 high frame rate variants by @nickswalker in #66
- Mordernized the library to follow contemprorary Python module structure by @eoyilmaz in #68
- Develop by @eoyilmaz in #59
New Contributors
- @nickswalker made their first contribution in #66
Full Changelog: 1.4.1...1.5.0
1.4.1
1.4.0
(description from #52)
Added a mean to get the timestamps of a given SMPTE Timecode. Two timebases are considered:
- Video system time:
to_systemtime() - Real time:
to_realtime()
NTSC framerates will return different values as the system time is not aligned to the wall-clock time. All others should return the exact same value.
DF 29.97:
> tc = Timecode("29.97", '00:59:59;29')
> tc.to_systemtime()
'01:00:00.000'
> tc.to_realtime()
'00:59:59.996'NDF 29.97:
> tc = Timecode("29.97", '00:59:59:29', force_non_drop_frame=True)
> tc.to_systemtime()
'01:00:00.000'
> tc.to_realtime()
'01:00:03.600'PAL 50:
> tc = Timecode("50", '00:59:59:49')
> tc.to_systemtime()
'01:00:00.000'
> tc.to_realtime()
'01:00:00.000'I did not implement setters as I don't think there's a meaningful usage or need to them.
Hopefully this may help others understand better Timecodes running at different rates and the relations to the wall-clock time.
The second commit is to preserve the drop frame flag on elementary operations.
> tc = Timecode(29.97, '00:00:00:00', force_non_drop_frame=True)
> assert tc.drop_frame is False
> tc = tc + 1
> tc
'00:00:00:01' #before: '00:00:00;01'
> tc.drop_frame
False #before: TrueThanks for @cubicibo for contribution.
As usual, version 1.4.0 is also released to PyPI and running pip install timecode will install it.
1.3.2
1.3.1
1.3.0
-
Fix: Fixed a huge bug in 29.97 NDF and 59.97 NDF calculations introduced in v1.2.3.
-
Fix: Fixed
Timecode.frameratewhen it is given as23.98. Theframerateattribute will not be forced to24and it will stay23.98. -
Update:
Timecode.tc_to_frames()method now accepts Timecode instances with possibly different frame rates then the instance itself. -
Fix: Fixed
Timecode.div_frames()method. -
Update: Test coverage has been increased to 100% (yay!)
1.2.5
-
Fix: Fixed an edge case when two Timecodes are subtracted the resultant Timecode will always have the correct amount of frames. But it is not possible to have a Timecode with negative or zero frames as this is changed in 1.2.3.
-
Fix: Fixed
Timecode.floatproperty for dropframe timecodes.
1.2.4
1.2.3
- Update: Passing
frames=0will now raise a ValueError. This hopefully will clarify the usage of the TimeCode as a duration. If there is no duration, hence theframes=0, meaning that the number of frames of the duration that this TimeCode represents is 0, which is meaningless. - Update: Also added some validation for the
framesproperty (oh yes it is a property now).