sd_ass: introduce sub-ass-prune-delay

[llyyr]

No description provided.

[sfan5]

do we really have to make this configurable?
if you seek events will be re-read anyway so something like 10s should be guaranteed safe

[kasper93]

Why is this even configurable on libass side? Why can't they manage their internal memory cache?

[llyyr]

Why is this even configurable on libass side? Why can't they manage their internal memory cache?

This is a new API, the use case is playback of a video file made solely out of ASS vector-art (>1TiB file in total). libass currently keeps all events in memory until ass_flush_events or ass_free_track is called. libass/libass#747

do we really have to make this configurable?

Setting it to a really small number should be fine too, but there may be use cases where you want it to be 0.

[llyyr]

Changed it to just unconditionally enable pruning if the API is available. I tested it briefly and nothing seems broken by it

Scratch that, this breaks if a subtitle needs to be re-rendered because the user switched play-dir during runtime. I don't think we can enable this at all then without re-decoding events in the event of play-dir, but how much do we care about reverse playback anyway?

[cubicibo]

Why is this even configurable on libass side? Why can't they manage their internal memory cache?

libass cannot know the user intention and use-case.

• User may parse an entire script once then perform random seek forward and backward: libass must not do anything.
• User may only render content incrementally: libass can optionally discard expired events.
• User can playback content where subtitle and video packets are multiplexed. Relying on libass cache can be faster than flushing everything and re-parsing.
• User can watch a continuous stream with closed captions (e.g. Twitch): pruning must be performed to prevent a (long-term) memory leak.

This should probably be enabled by default with a reasonable time window for ASS tracks multiplexed with AV content, like MKVs, or with livestreams that include closed captions rendered by libass.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[sfan5]

I tested it briefly and nothing seems broken by it

Wouldn't it also break sub-seek if the previous event is older than prune-delay?

[llyyr]

Wouldn't it also break sub-seek if the previous event is older than prune-delay?

Yes, so sub-seek and switching to play-dir=- during runtime is broken if we enable it unconditionally

[Samillion]

This would solve #9014 right?

[llyyr]

This would solve #9014 right?

No, this will only apply to the subtitle track, not the OSD. I don't believe this is necessary or even warranted for the OSD since as avih said in that issue: Sure, with OSD/OSC it uses more ram (and grows quicker initially), because libass has a big cache. However, that should eventually stop growing

It shouldn't be growing infinitely in the first place, so if it does that's a whole another issue.

[Samillion]

Noted. Thank you for the response.

[kasper93]

Have anyone tested it?

[llyyr]

Have anyone tested it?

Yes, I tested it. Works as expected, I listed the things it breaks in the docs that's why I don't think we can enable it by default unfortunately