6.22.1 - A seek retires an end it could not confirm

Drop-in from 6.22.0, no API change. One fix: a subtitle that outlives the position it was authored at.

A cue with no end of its own

A PGS composition carries no end. FFmpeg reports end_display_time = UINT32_MAX, the decoder stamps the cue with that open-ended placeholder, and the successor composition's trim closes it. In steady state insert and trim land within a frame of each other and nothing untoward shows.

A seek defeats both bounds at once. The successor arrives only when the new landing point's first composition does, which on a sparsely authored stretch is tens of seconds later, and the retention prune filters on endTime, which a placeholder end can never age out of however far the playhead moved. So the pre-seek cue stayed in the published window with a window covering the new playhead, and every host that asks which cue is active rendered it. Reported on 6.21.0 by @rrgomes: a cue authored at 2549.8 s read as active at 2855.15 s and held the overlay for 24.5 s until a real cue displaced it.

A reset tick now closes every still-open cue that began before its reconstruction window, at that window's start. That boundary is the one the engine already defines as how far it looks back at a landing: nothing before it is re-decoded, so nothing there can be confirmed as still open. The cue stays in the retained list for a backward seek, only its unconfirmed end retires, and an authored duration is never touched, which is what separates this from dropping the pre-seek set wholesale.

The store is not the only holder of an open cue. The #100 stale-arrival gate keeps a held arrival and a reconstruction candidate carrying the same placeholder end, and the first post-seek trim closes those at a successor start ahead of the new playhead, which republishes pre-seek history as the active line. Both belong to the position the tick is leaving, so a reset now drops them before arming the next pass. Anything that can still claim the landing comes back through the backscan's own re-decode.

Verifying it

play --subs pgssub --seek-every 15 --seek-pattern 300 against an embedded PGS track whose last composition has no clear:

CUE #3 20.00-4294987.29 [bitmap]
SEEKCHURN seek(to: 300.00)
SEEKLANDED target=300.00 in 38ms (clock=300.00)
TRIM #3 -> end=285.40

On 6.22.0 the same run produces no TRIM line and the cue keeps its placeholder end for the rest of the session.

Hosts that already discard cues starting far behind the playhead need no change; they can drop that filter.