Repository navigation
Minor inconsistencies in frame numbers #242
Description
Bug/Issue Description:
There is a minor inconsistency in the reports.
Comparing the Scenes.csv file and the stats.csv :
Start and End of scenes
In Scenes.csv I think the scenes are expressed wrong IMO.
While the Start frame is correct, the end frame is belongs to the next scene.
Right now we are saying.
start: 0, end: 20;
start: 20, end: 35;
start: 35, end: 40;
While it should be
start: 0, end: 19;
start: 20, end: 34;
start: 35, end: 40;
number of frames, lengths and timestamps should be corrected accordingly according for each entry.
Zero-based vs One-based frame numbers
Another thing is that Scenes.csv considers the first frame to be number 1, while Stats.csv considers it to be number 0.
Personally I think having the first frame to be number 1 is a good human friendly choice (against what ffmpeg does, which is zero-based). So this should be unified, not only in the output but also in the functions which I haven't looked at.
UPDATE: Stats.cvs for detect-content is skipping frame no. 0, that is why I thought it was one-based.
Required Information:
Provide the following information to assist with reporting the bug:
- Provide a full copy of the command line options you are using, for example:
scenedetect --input "movie.mp4" --stats movie.stats.csv detect-content list-scenes
Thank you for this piece of software, It is really awesome
Activity
Breakthrough commentedon Sep 19, 2021
The statsfile doesn't output frames for which no stats are created. There cannot be any stats for frame 0 since stats are measured as the difference from the previous frame. Thus only frame 1 can have stats.
I am considering increasing the index from 0 -> 1 to match ffmpeg in the next release. When this is done though, the first frame you will see in the statsfile would then be frame 2, for the same reasons as above.
I will consider adding an empty row for the time being however as there could technically be stats calculated on the current frame only, like
detect-thresholddoes.Breakthrough commentedon Jan 15, 2022
Also after revisiting this, I'd like to point out:
I believe ffmpeg is 1-based in terms of frame indices (e.g. frame 1 has a presentation time of 0.0s). To clarify, PySceneDetect's output is currently 0-based. The correct behavior from what you posted above should be:
So assuming we have a video at 1 FPS which is 7 seconds long and has 4 scenes of length 1, 2, 1, and 3 seconds, respectively. We should have the following invariants on the time/frame numbers's that are output for each scene:
Number
(sec)
(frame)
(sec)
(frame)
(sec)
(frames)
Internally within the Python API scenes will have a different representation (specifically the end frame needs to include the presentation time), so noting this here for now until it's documented in v1.0. E.g. the scenes above would be stored as (0, 1), (1, 2), (2, 4), (4, 6).
[-]Minor inconsistencies[/-][+]Minor inconsistencies in frame numbers[/+]Breakthrough commentedon Mar 13, 2022
Random, but I also see now that the duration also suffers from an off-by-one error, e.g. specifying
time -d 10will result in 11 frames being processed.