Shift+Forward/Backwards not working properly with MKV built in subtitles

[stingusss]

System and IINA version:

• macOS Sonoma 14.4.1
• IINA 1.3.4 Build 140

Expected behavior:
Shift+Forward/Backwards to skip to the next/previous subtitle.

Actual behavior:
The feature works 100% properly if the subtitles are stored as an external file.
If the subtitle is a part of the MKV - it works only if the subtitle has been "cached" already. Nothing will happen if you hit Shift+Forward while the next subtitle is 10 seconds away.
Use case example: you're watching something with an opening and you want to skip it. You know that the opening itself has no subtitles and you want to skip to the first dialog. Hitting Shift+Forward will work only if the subtitles are stored in a separate file.
It will also work if you run through the episode and "cache" all the lines - then the feature would work.

Steps to reproduce:
Open any MKV with built in subtitles. Hold (or press repeatedly) Shift+Forward. You will get stuck when there will be like 5+ gap between subtitles.
But you'll be able to go through the whole episode if the subtitles are external (like .srt file)

• MPV does not seem to have this feature at all.

How often does this happen?
100% of the time.

Thank you for your work!

[low-batt]

For audio/video playback and subtitle rendering support IINA is using a library from the mpv project. It is mpv that is decoding the subtitles contained within the mkv and rendering them into a video frame that IINA then displays.

The key ⇧→ is bound to the mpv sub-seek command:

sub-seek <skip> <flags>
Seek to the next (skip set to 1) or the previous (skip set to -1) subtitle. This is similar to sub-step, except that it seeks video and audio instead of adjusting the subtitle delay.

Secondary argument:

primary (default)
Seeks through the primary subtitles.
secondary
Seeks through the secondary subtitles.

For embedded subtitles (like with Matroska), this works only with subtitle events that have already been displayed, or are within a short prefetch range.

This is a known mpv restriction with embedded subtitles. From this comment on mpv issue mpv-player/mpv#411:

You can just pass the mkv file to --sub. Note that for text subs, this will read the entire mkv file when selecting the subtitle track. It also might do some unwanted processing on ASS subtitles.

That was 2013. I think --sub turned into --sub-file.

Try using the Load External Subtitle… menu item under the Subtitles menu to load the mkv file as a subtitle file. See if that works.

[krackers]

See also #4172

[low-batt]

Thanks for mentioning #4172. I had totally forgotten about that issue.

[stingusss]

Try using the Load External Subtitle… menu item under the Subtitles menu to load the mkv file as a subtitle file. See if that works.

Tried that and it helped - were able to go through the whole file without "precaching". But that's not really handy :)

Will try the #4172 thing.

[low-batt]

I believe the #4172 thing is the cache settings discussed in issue #4881. By reading ahead and caching mpv will see the next subtitle. I would think this would have trouble with long sections that don't have subtitles. The readahead would have to be long and the cache size would have to be big to work around such portions of the video. @krackers knows more than me about this.

[krackers]

Yes correct, your demux cache size would need to be large enough such that we can demux-ahead the next sub packet. Since subs are non-eager streams, they are usually demuxed along with video. So this means that you need to set demux cache to basically MAX{# video packets between 2 subs}. This can technically be unboundedly large (you can always construct pathological files which have a sub at the beginning, sub at the end, and nothing in between), but in practice probably buffering ~5min worth of video would suffice.

If you are not concerned with memory usage, setting demux cache max bytes to a large value like 300MB and then setting cache-secs to 5min is an option. This will limit the cache to min{300 mb, 5min} which should in practice work for most videos, while providing an upper bound on memory usage for pathological cases.