You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
On Kodi we use different ways to meet different needs, since we use libass especially to display others subtitles formats
main cases:
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.
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
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 orass_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.
The text was updated successfully, but these errors were encountered: