Minor inconsistencies in frame numbers

[eksperimental]

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:

1. 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

[Breakthrough]

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-threshold does.

[Breakthrough]

Also after revisiting this, I'd like to point out:

against what ffmpeg does, which is zero-based

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:

start: 1, end: 19;
start: 20, end: 34;
start: 35, end: 40;

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:

Scene Number	Start (sec)	Start (frame)	End (sec)	End (frame)	Duration (sec)	Duration (frames)
1	0.0	1	1.0	1	1.0	1
2	1.0	2	3.0	3	2.0	2
3	3.0	4	4.0	4	1.0	1
4	4.0	5	7.0	7	3.0	3

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).

[Breakthrough]

Random, but I also see now that the duration also suffers from an off-by-one error, e.g. specifying time -d 10 will result in 11 frames being processed.