Open joosepelias opened 1 year ago
I found this from the mpv manual:
Ctrl+LEFT and Ctrl+RIGHT Seek to the previous/next subtitle. Subject to some restrictions and might not always work; see sub-seek command.
Might this be why it isn't working reliably?
I believe your analysis is correct and the faulty behavior is due to a documented restriction with respects to embedded subtitles, specifically this from the mpv manual sub-seek command:
For embedded subtitles (like with Matroska), this works only with subtitle events that have already been displayed, or are within a short prefetch range.
The reported behavior matches up with the limits of this feature.
For IINA this is an "upstream" issue as any fix would have to be made by the mpv project.
Enable demux cache can be a workaround. I think internally it relies on libass reporting the pts of the next subtitle, but in order to do so we must have demuxed far enough ahead that we have encountered the relevant events. But by default mpv uses I think 1 sec readahead which may not work well for certain types of files. External subtitle tracks work fine because they use different fetch behavior, they are are eagerly demuxed as opposed to lazily demuxed so it effectively always reads ahead to next packet (actually it's even stronger guarantees, as an implementation detail the entire sub is demuxed one-shot and events frontloaded into libass)
The "Seek to next subtitle" or "sub-seek 1" is not always working. It seems that the player doesn't know there are any subtitles to skip to, because it skips backwards normally and if I regular skip over the next subtitle, then I will be able to skip to it with the "Seek to next subtitle" command if I get to a time before it. I am using an .mkv file.