Skip to content

6.0.2 - Subtitle-resolution statement

Choose a tag to compare

View all tags
@superuser404notfound superuser404notfound released this 29 Jul 15:30
6.0.2
a216ca2

A diagnostic addition. No API change, no behaviour change; nothing in the playback path moves.

Added

  • The subtitle path now states how far display-state determination has advanced, on the absolute source axis and fenced by generation. After a far seek lands, no surface could tell "the pipeline has determined the display state at this position" from "it has produced nothing yet". On a PGS track with no acquisition point those two are indistinguishable from outside, and for a conformance harness that distinction is the entire adjudication. The memprobe's prefetch fragment is playhead-relative and carries no generation, so a line from just before a seek reads the same as one just after it landed; the #151 session lines are explicit about EOF but state the harvest frontier, not how far determination has advanced; the drain tick logged nothing at all. Requested by cmcpherson274.

    One line per active drain target: [AetherEngine] #250 subtitle-resolution loadGen=3 seekGen=7 stream=4 coveredFrom=1189.00 resolvedThrough=1218.00 via=prefetch decodedThrough=1204.00 reason=reconstruction

    resolvedThrough is the decode window clamped to a harvest frontier. Deliberately neither of the two obvious candidates: the window's own lead edge (playhead + 60 s) would claim determination over bytes nobody read, which is exactly the ambiguity the line exists to remove, and the drain cursor is the last actual cue, which on a sparse or forced track stands still for minutes so every dialogue pause would read as unresolved. via states which frontier bounds the claim, and therefore what the number is worth: prefetch is exact, since #230 the side reader's banked position is the read position on the source axis; eof is the strongest state, the reader reached end of stream so an empty position means "no cue here" rather than "not yet"; pump is the weak one and says so, since the producer tap has no read-position surface and the claim collapses to the drain cursor.

    Emitted at a post-seek reconstruction window, on the 30 s memory-probe cadence, at prefetcher EOF, and whenever the frontier's source changes, which is how a #231 mid-session prefetcher death stops passing silently. Not per drain tick: the drainer runs at 2 Hz per channel and a span restated four times a second buries the transitions that carry the information.

  • The #151 re-anchor request carries the seek generation that asked for it. Since #240 a prefetch session survives a seek, moving its cursor in place instead of rebuilding, so a fence captured at session start goes stale on the first in-place move, and goes stale in exactly the superseded-seek case a fence exists to resolve. The generation is stamped after the reposition, so the window between the request and the seek that serves it reads as unresolved rather than validating a position the reader has not reached yet. A frontier fenced to a superseded load or seek is not usable at all.

Changed

  • The prefetcher's dead readPosition local is gone. It was written in three places and read in none, and its comment claimed it fed the link arbitration's lead, which it has not since the arbiter took yieldedSeconds instead. The tvOS build had been warning about it.

Upgrading

.package(url: "https://github.com/superuser404notfound/AetherEngine", from: "6.0.2")

Drop-in from 6.0.1. SubtitleForwardPrefetcher.SideReaderReanchor.request and take changed shape, both internal.

Assets 3
Loading