Releases: eoyilmaz/timecode
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: True
Thanks 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.framerate
when it is given as23.98
. Theframerate
attribute will not be forced to24
and 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.float
property for dropframe timecodes.
1.2.4
1.2.3
- Update: Passing
frames=0
will 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
frames
property (oh yes it is a property now).