Stylized ASS subs are not rendered properly

[fivepandasna]

What happened?

Heavily styled ASS subtitles do not render correctly with libass (applies to Sodalite). Some subtitle events are missing, causing parts of the subtitle track to disappear or render inconsistently.

Steps to reproduce

1. Play a video with heavily styled ASS subtitles (I can provide a sample track if needed)
2. Verify that some subtitle styles, layers, or dialogue events are missing or rendered incorrectly

AetherEngine version or commit SHA

5.20.7

Host app

Sodalite

Platform

iOS

OS version

iPadOS 26.5.2, iOS 26.5.2

Device / chip

iPhone 17, iPad mini gen 7

Playback path

Native AVPlayer

Source media (for playback bugs)

No response

Error codes / log lines

Anything else

I added logging to a custom player using AetherEngine and compared the processed events against the source ASS file. By the time playback had reached ~30.9s, processEvent had only been called 245 times, even though the ASS file contains 2,054 Dialogue events with start times less than or equal to the latest timestamp received by the player (~90.4s).

The number of processed events closely matches the number of unique timestamp ranges: there are only 268 unique (start, end) timestamp pairs in that same range. This suggests that multiple valid ASS dialogue entries sharing identical timestamps are being collapsed somewhere before AetherPlayerWrapper receives them.

While investigating, I found the following in SubtitlePacketStore.appendLocked:

let insertAt = entries.firstIndex { $0.ptsSeconds >= ptsSeconds } ?? entries.count
if insertAt < entries.count, entries[insertAt].ptsSeconds == ptsSeconds {
    bytes -= entries[insertAt].payload.count
    entries[insertAt] = entry        // overwrites existing entry
} else {
    entries.insert(entry, at: insertAt)
}

This appears to make ptsSeconds effectively unique, meaning subtitle packets with identical PTS values overwrite each other instead of being stored as separate entries.

[superuser404notfound]

Fixed in 5.25.2, via #237.

What landed is that PR plus three follow-ups, described in the PR thread: a burst on a shared PTS is stored in harvest order rather than reversed, the insert position is found by binary search instead of a scan from the front of the array, and two test fixtures that had encoded the old collapse were corrected.

Leaving this open for a retest against the tag. Beyond the event count, the thing worth checking on a heavily styled track is the order the burst arrives in: with several overlapping lines authored on one Start/End, the sequence reaching processEvent should now match the order in the source file, since that is what decides how a renderer stacks them.