Use duration of last frame

[moi15moi]

This is needed for VFR video.
This depend on this PR: FFMS/ffms2#464
I'm waiting the ffms2 PR before merging this one.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 96.98492% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.77%. Comparing base (9c05900) to head (d12579e).

Files with missing lines	Patch %	Lines
video_timestamps/abc_timestamps.py	87.50%	3 Missing ⚠️
video_timestamps/text_file_timestamps.py	96.07%	2 Missing ⚠️
video_timestamps/video_timestamps.py	90.90%	1 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #21      +/-   ##
==========================================
- Coverage   97.84%   97.77%   -0.07%     
==========================================
  Files          17       17              
  Lines        1622     1666      +44     
==========================================
+ Hits         1587     1629      +42     
- Misses         35       37       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[moi15moi]

This PR cause problem for CFR video when trying to calculate the PTS over the video duration.
It happen when the container/codec frame duration doesn't have the same timebase as the pts.

For example, for mkv file, the duration can be setted with BlockDuration or it will fallback to the track default Duration. For both of them, their value doesn't seems to depend on the same timebase has the PTS because, if we extract the timestamps of this sample_9_frames.zip, we get this:

# timestamp format v2
Frame 0: 0
Frame 1: 42
Frame 2: 83
Frame 3: 125
Frame 4: 167
Frame 5: 209
Frame 6: 250
Frame 7: 292
Frame 8: 334
Frame 8 + duration: 375.708333 which will be truncated to 375 by ffmpeg

375.708333 correspond to the last frame pts (334) + the default duration (41708333), so it give this number that doesn't respect the timebase 1/1000.
Normally, the frame 9 would be 375, so we could think that we just need to floor the result like ffmpeg does, but it isn't the case. Let's see a another example to example why.

With this sample, sample_8_frames.zip, we have those timestamps:

# timestamp format v2
Frame 0: 0
Frame 1: 42
Frame 2: 83
Frame 3: 125
Frame 4: 167
Frame 5: 209
Frame 6: 250
Frame 7: 292
Frame 7 + duration: 333.708333 which will be truncated to 333 by ffmpeg

Normally, the frame 8 would be 334, so in this case, we would need to round the result.

So, in brief, since it add the PTS of the last frame (which is rounded) + the default duration, the result is basically junk.
Also, ffmpeg store the frame duration with the same timebase as the PTS, so it actually trunk the duration.

There isn't any way to solve this issue.
This PR is great for VFR video, but for CFR video, it break the logic to resolve the timestamps over the video duration.
I don't know what I should do.