You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Inconsistent processing length when end/duration is set as frames (CLI-only) #341
[PySceneDetect] PySceneDetect 0.6.2
[PySceneDetect] Downscale factor set to 5, effective resolution: 256 x 108
[PySceneDetect] Detecting scenes...
Detected: 0 | Progress: 90%|███████████████████████████████████████████████████▎ | 9/10 [00:00<00:00, 346.18frames/s]
[PySceneDetect] Processed 9 frames in 0.0 seconds (average 300.01 FPS).
[PySceneDetect] Detected 1 scenes, average shot length 0.4 seconds.
May be related to the fixes made for #307. End time should be exclusive, so setting -e 10 should stop after processing 10 frames, e.g. the correct output here should be 10/10. This also affects the output for time arguments --duration and --end. For example if time --end 10 is specified, the last frame that will be processed is actually frame 9.
With --duration this happens inconsistently. If no start time is specified, 9 frames are processed. However if start time is set to frame 2, it actually stops processing at frame 10. When setting start/duration/end as frames, this should be reflected in the output correctly. This does mean that when specifying time values as frame numbers, they will be treated differently, but this should lead to more expected behaviour.
The following changes will be made but will ONLY affect specifying times as exact number of frames (using timecodes or seconds is unaffected):
start as frame number excludes presentation time
end and duration as frame number should include presentation time
duration as frames should process exactly that amount of frames
end - start should process (1 + end - start) frames, such that setting start == end still processes a single frame
end as frame number should be inclusive and indicate the last frame to process (currently it excludes presentation time and stops at the end of the previous frame)
duration as frame number should stop at frame (start + duration - 1)
progress bar should match exact amount of frames being processed (e.g. same as duration or end - start)
changed the title [-]Progress bar incorrect denominator when `time --end` is set[/-][+]Inclusion of presentation time when end time is set as frames is inconsistent[/+]on Feb 8, 2024
changed the title [-]Inclusion of presentation time when end time is set as frames is inconsistent[/-][+]Inconsistent presentation time for end/duration as frames[/+]on Feb 8, 2024
changed the title [-]Inconsistent presentation time for end/duration as frames[/-][+]Inconsistent processing length when end/duration is set as frames (CLI-only)[/+]on Feb 8, 2024
Activity
[-]Progress bar incorrect denominator when `time --end` is set[/-][+]Inclusion of presentation time when end time is set as frames is inconsistent[/+][-]Inclusion of presentation time when end time is set as frames is inconsistent[/-][+]Inconsistent presentation time for end/duration as frames[/+][-]Inconsistent presentation time for end/duration as frames[/-][+]Inconsistent processing length when end/duration is set as frames (CLI-only)[/+][tests] Expand `time` command tests
[cli] Correct duration/end times for presentation time when set as fr…
[tests] Expand `time` command tests
[cli] Correct duration/end times for presentation time when set as fr…