sub: don't potentially discard too many subtitles on seek

The accepts_packet packet callback is supposed to deal with subtitle
decoders which have only a small queue of current subtitle events (i.e.
sd_lavc.c), in case feeding it too many packets would discard events
that are still needed.

Normally, the number of subtitles that need to be preserved is estimated
by the rendering pts (get_bitmaps() argument). Rendering lags behind
decoding, so normally the rendering pts is smaller than the next video
frame pts, and we simply discard all subtitle events until the rendering
pts.

This breaks down in some annoying corner cases. One of them is seeking
backwards: the VO will still try to render the old PTS during seeks,
which passes a high PTS to the subtitle renderer, which in turn would
discard more subtitles than it should. There is a similar issue with
forward seeks. Add hacks to deal with those issues.

There should be a better way to deal with the essentially unknown
"rendering position", which is made worse by screenshots or rendering
with vf_sub. At the very least, we could handle seeks better, and e.g.
either force the VO not to re-render subs after seeks (ugly), or
introduce seek sequence numbers to distinguish attempts to render
earlier subtitles when a seek is done.

1 files changed, 1 insertions, 1 deletions

diff --git a/sub/sd.h b/sub/sd.h
index c8056d379f..178a6d5be6 100644
--- a/sub/sd.h
+++ b/sub/sd.h
@@ -34,7 +34,7 @@ struct sd_functions {
     void (*select)(struct sd *sd, bool selected);
     void (*uninit)(struct sd *sd);
 
-    bool (*accepts_packet)(struct sd *sd); // implicit default if NULL: true
+    bool (*accepts_packet)(struct sd *sd, double pts); // implicit default if NULL: true
     int (*control)(struct sd *sd, enum sd_ctrl cmd, void *arg);
 
     void (*get_bitmaps)(struct sd *sd, struct mp_osd_res dim, int format,