Skip to content

Conversation

@moi15moi
Copy link
Contributor

@moi15moi moi15moi commented Jan 1, 2026

I believe mpv calculate the time of each frame like this (I have no proof)

time_of_frame_x = (time_of_frame_x - time_of_frame_0) + (AVStream::start_time - AVFormatContext::start_time)

In ffms2 case, I think time_of_frame_0 is always equals to AVStream::start_time (this might not be the case!!!) and they are represented by FFMS_VideoProperties::FirstTime.

This PR is a draft because i'm not sure that this properly emulate how mpv works.
I just wanted to show you a possible fix.

Fix #172

arch1t3cht and others added 2 commits December 31, 2025 21:27
This reverts commit 1dedfb1.
Such files exist in the wild (one example being a large set of old CR
rips, see https://redvice.org/2018/crunchyroll-83ms-delay/) and players
like mpv also respect this video delay (at least they do now, they might
not have when the linked commit was made).

Fixes TypesettingTools#21.
Fixes TypesettingTools#169.
I believe mpv calculate the time of each frame like this (I have no proof)
```
time_of_frame_x = (time_of_frame_x - time_of_frame_0) + (AVStream::start_time - AVFormatContext::start_time)
```

In ffms2 case, I think `time_of_frame_0` is always equals to `AVStream::start_time` (this might not be the case!!!) and they are represented by `FFMS_VideoProperties::FirstTime`.

Fix arch1t3cht#172
@moi15moi
Copy link
Contributor Author

moi15moi commented Jan 2, 2026

ffms2 case, I think time_of_frame_0 is always equals to AVStream::start_time (this might not be the case!!!)

Actually, yes and no.
If you use the sample in this issue with ffmpeg 8.0.1 or less, the first frame PTS is NOT the same as AVStream::start_time, but this was indeed a bug, so i'm not sure if that's relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix .m2ts video timecodes

2 participants