Overhaul Timecode APIs

[LukeM-Github]

I glanced at the code, it seems to be assuming constant frame rate.

[Breakthrough]

This is correct.

Adding support for variable frame rate videos will really drive a lot of underlying API changes, which I am willing to do, but will require to rethink how timestamps are stored within PySceneDetect internally to achieve this in an efficient matter. I'll try to come up with a good design,

[Breakthrough]

I think I have a good initial design, will post here when there are some unit tests showing how timecodes will be stored in v1.0. The idea is to store both a frame number, time in seconds, framerate, and a tag if the framerate is variable or not. Unit tests should make this much more clear, so will post an update here when they are ready in the 1.0 branch.

[Breakthrough]

Timecodes as of v0.6 are now obtained directly from the underlying VideoStream (via OpenCV VideoCapture or PyAV), but timecode calculations still assume a constant frame rate. This should improve accuracy for the majority of use cases, but there still remains a significant amount of work to be done for supporting VFR material.

Anyone willing to share samples for testing is encouraged to upload them here to this issue for analysis.

[hokaso]

Timecodes as of v0.6 are now obtained directly from the underlying VideoStream (via OpenCV VideoCapture or PyAV), but timecode calculations still assume a constant frame rate. This should improve accuracy for the majority of use cases, but there still remains a significant amount of work to be done for supporting VFR material.

Anyone willing to share samples for testing is encouraged to upload them here to this issue for analysis.

I have a better idea, that is, first transcode the vfr video into a smaller size cfr video, then perform scene detection on the cfr video, and then apply the cfr timeline information to the vfr video. I have tested, is completely no problem.