Conversation
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
Actually, yes and no. |
|
I'm fairly sure that mpv does not read |
|
Moreover, There's probably no good way to fix this, and the simplest solution is to just a) rebase by start_time, which at least matches mpv, and b) simply alert and ask the user whenever the first timestamp is not 0. I'm mostly ffmpeg's behavior here for future reference so I don't forget this later. |
I believe mpv calculate the time of each frame like this (I have no proof)
In ffms2 case, I think
time_of_frame_0is always equals toAVStream::start_time(this might not be the case!!!) and they are represented byFFMS_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