Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API to discard older events from memory #747

Open
astiob opened this issue Apr 8, 2024 · 2 comments
Open

API to discard older events from memory #747

astiob opened this issue Apr 8, 2024 · 2 comments

Comments

@astiob
Copy link
Member

astiob commented Apr 8, 2024

When playing a Matroska file, the ASS track is usually streamed in an incremental fashion: new events are added via ass_process_chunk when the current playback timestamp reaches them. This avoids having to read the whole file at once. Playback proceeds continuously with a monotonically increasing timestamp.

Currently, libass keeps all events that are added in this manner in memory until ass_flush_events is called to discard all events at once or ass_free_track is called to discard the entire track. This causes the memory usage to rise steadily as playback continues. With reasonably small subtitle tracks, this is unnoticeable, but DataHoarder’s monstrous bitmap (1.1 TiB ASS file!) and vector-art (hundreds of MiB per file) conversions are an easy example of where this matters a lot. It’s not unfathomable that this might matter in slightly more realistic cases, too.

However, ASS events whose ending timestamp has passed are actually no longer necessary to render the subtitles, so they could be discarded, freeing up memory and speeding up event lookup. This probably needs a new API by which the media player could negotiate the cutoff timestamp with libass.

When seeking (jumping) to an earlier timestamp, this will necessitate reloading the earlier subtitles, but this already happens in general, as the seek may target a timestamp that’s earlier than any timestamp the user has already played. I’m not sure whether players implement optimizations to avoid reloading subtitles when it’s known that they’re already cached, but I suspect not.

@clsid2
Copy link

clsid2 commented Apr 8, 2024

In case of MPC-HC it flushes on every seek (for embedded subs). And ass_process_chunk is called whenever the splitter provides subtitle data. So data is reloaded after jumping back. Auto discarding old events would be totally fine.

@CastagnaIT
Copy link

On Kodi we use different ways to meet different needs, since we use libass especially to display others subtitles formats
main cases:

  1. For others subtitles formats, we convert in full the original file to ass format,
    then we use ass_alloc_event to add converted sub data as events,
    this is done all-in-one (usually) at the beginning of playback.
    In this case, we need to disable the new "auto-discarding of old events", since data are converted and added as events only once.

  2. For video streaming (especially live streams) or however demuxed data, where the demuxer provide packets, we always use ass_alloc_event for converted subs (except for ass data format we use ass_process_chunk) in this case usually the "video seek" execute ass_flush_events to discard old events, and new fresh data is provider by the demuxer after the seek.
    But on live streaming the "seek" is not always available, and currently we lack a way to delete old events,
    "auto-discarding of old events" can help to free memory.

so auto-discarding old events in general would be fine

we need attention regarding point 1, that must avoid to use the "auto-discarding", otherwise it becomes a breaking change that forces us to overhaul the entire subtitles management on Kodi that it is too large a job,
but from your sentence it seems it is already the intention to provide a kind of possibility, so it should be fine

This probably needs a new API by which the media player could negotiate the cutoff timestamp with libass

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants