Seek timing calculation occasionally uses stale reference from the previous seek, in one case triggering a false "audio lead exhausted" rebuffer pause

[classicjazz]

What happened?

Twice, a seek's landing diagnostics compute a delta value whose magnitude closely matches the distance to the previous seek's target rather than a normal frame-to-frame or lead value:

• Cosmetic case (FileB, seek#6, target=1111.34s, preceded by seek#5 target=949.74s — gap 161.60s): dpts=41.0/159367.0 (159.367s) appears in a single SWDiag sample, in a file otherwise showing dpts=41.0/42.0 throughout. No visible playback impact — it self-corrects on the next sample.
• Severe case (FileI, seek#5, target=1898.06s, preceded by seek#4 target=1453.92s — gap 444.14s): vLead reads -443.36, and the engine's own audio-lead check trips:

  [SWHost] audio lead exhausted (-440.08s); pausing clock for rebuffer
  [AudioOutput] pause at t=1898.899
  

  This forces an actual, unwanted playback pause. The next sample shows dpts=16.5/442842.5 (442.84s) and layerDrop jumps by 33 in that single interval — the largest single-step drop count seen in any session tested.

Steps to reproduce

1. Open a VC-1 file (reproduces on both a progressive file, FileB, and an interlaced file, FileI, so it isn't deinterlace-specific).
2. Perform a sequence of programmatic seeks to varied, non-adjacent timestamps.
3. Watch for a SWDiag sample whose dpts or vLead magnitude is on the order of hundreds of seconds — in the FileI case this crossed the internal rebuffer threshold and produced a visible pause; in the FileB case it stayed under threshold and was only visible in diagnostics.

AetherEngine version or commit SHA

6.68.0

Host app

AetherPlayer

Platform

macOS

OS version

Mac OS 27

Device / chip

M1 Max Mac Studio

Playback path

Software (dav1d) host

Source media (for playback bugs)

No response

Error codes / log lines

Anything else

In both cases the anomalous magnitude is very close to the gap between the current seek's target and the immediately preceding seek's target (161.6s vs. 159.4s reported; 444.1s vs. 442.8s/443.4s reported) — not the seek's actual jump-from-playhead distance, and not a value that appears in any other seek in these sessions. That strongly suggests some piece of seek-landing bookkeeping (the per-frame timestamp window, and/or the audio-lead reference used by SWHost) is occasionally not resetting to the new seek's landing point and is instead diffing against a stale value left over from the prior seek. Because this fed into the audio-lead-exhaustion check in the FileI case, it's a real, user-visible defect (an unexpected pause during normal seeking), not just a diagnostic artifact — worth prioritizing over the FileB case even though that one is more benign. I don't have source access to confirm the exact mechanism, so this is offered as a strong correlational pattern for someone with access to SWHost's seek-landing code to investigate, not a confirmed root cause.

[superuser404notfound]

Both numbers are one mechanism, and the correlation spotted here is the right one. Fixed on main in 4c286881 (merge f3c312ac), not in a release yet.

What was happening. seek(to:) flushes the video decoder, the audio decoder, the renderer and the audio output, and then AWAITS the demuxer reposition. That await was added so a slow remote read cannot park the main thread, and it means the decode thread keeps running for the whole length of the reposition. The skip thresholds that reject a pre-seek frame were installed AFTER the landing. For the entire reposition window there was therefore nothing standing between a frame decoded from a packet read before the seek and the renderer, and it was taken.

One such frame is enough to poison both readings, because both are single-valued:

• _lastHandedPtsSeconds is the base the inter-frame spacing is measured from. It is cleared at the flush precisely so a seek does not report one enormous interval, and a stale frame arriving after the flush sets it again. The next frame is the real landing, and the interval between them is the jump.
• the frontier newestEnqueuedPtsSeconds is cleared at the flush for the same reason, and the same stale frame restores it to a pre-seek timestamp. vLead is that frontier minus the clock, so it reads the jump with a minus sign.

The audio half had no gate at all. The demux loop re-checks the seek generation before decoding a video packet, and its audio branch never did, so a pre-seek audio packet decoded across the flush was enqueued into the emptied audio queue and set lastEnqueuedAudioPtsSec. That marker is what the lead check measures against, so with the clock re-anchored at 1898.06 and the marker still at the pre-seek position, the lead read as exhausted and the clock was paused for a rebuffer that was not happening.

One correction to the reading, and it supports the diagnosis. The magnitude is not the distance between the two targets, it is the distance from the last frame handed over BEFORE the seek, which is the previous target plus however long it played. That is why the numbers are consistently a little short of the target gap: 161.60 against 159.367 is 2.2 s of playback after seek#5, and 444.14 against 442.84 is 1.3 s after seek#4. A stale reference from the previous seek's TARGET would have matched the gap exactly.

The fix is three gates, because no single one covers both directions:

1. The skip thresholds are armed before the reposition is awaited rather than after it. The target is known at that point, so there is no reason to wait.
2. The decoder callback drops a frame whose decode generation is not the live one. This is the only gate a BACKWARD seek has: a stale frame whose timestamp is past the new target clears the threshold on its way through rather than being stopped by it, and the hardware decoder answers on its own thread later still. Both directions were reachable, the two sessions here happened to be forward.
3. The audio branch re-checks the generation before decoding and again before enqueueing, since the flush can also land inside decode.

Regression tests cover the renderer half in all three shapes, including the backward one that the threshold alone does not catch.

On the ranking: prioritising the pause over the cosmetic case was right, and it is worth saying that the cosmetic case was the same defect the whole time, one that simply did not cross a threshold. A retest on the next release closes this.

[superuser404notfound]

Released in 6.68.2 (33c3816). Both consumers are on it: Sodalite 29344377, AetherPlayer 9d205d1, so the next AetherPlayer build carries the fix.

What the retest should show on the same seek pattern: no dpts or vLead sample carrying the seek distance, and no audio lead exhausted line on a landing that is not genuinely starved. The FileI case is the interesting one, since that is the session where it crossed the threshold.

[superuser404notfound]

AetherPlayer 0.17.2 is up with that engine, so there is a signed DMG to retest against rather than a source build: https://github.com/superuser404notfound/AetherPlayer/releases/tag/v0.17.2 (Sparkle will offer it to an existing install, build 67).

[classicjazz]

Update from AetherPlayer testing (build 0.17.2 (67), engine 6.68.2 — includes this fix):

Confirmed fixed: across three fresh sessions (FileI, FileB, FileJ) with seek patterns at least as aggressive as the original repro, audio lead exhausted and the associated forced pause do not appear anywhere in the logs.

Found what looks like a residual/related case though. On FileI and FileJ, when two very-large-distance seeks fire in quick succession (~2-3s apart), vLead reports a value in the thousands of seconds that closely matches the previous seek's jump distance — the same stale-reference mechanism this fix targeted, just showing up in the video-lead reading instead of the audio one.

FileI — seek to 2465.77 → seek to 168.62 → seek to 626.45, fired ~2-3s apart:

vLead=2301.93   (≈ the 2465.77→168.62 gap of ~2297s)

FileJ — seek to 2888.76 → seek to 418.12 → seek to 630.53:

vLead=2474.81, then vLead=2474.31   (≈ the 2888.76→418.12 gap of ~2470.6s)

Each of these coincides with a much larger-than-normal frame-drop burst (+44, +44, +25 across the three FileI seeks; +38, +18, +46 across the three FileJ seeks) — well beyond anything seen pre-fix.

I didn't reproduce this on FileB (progressive), but that session's back-to-back seeks were small-distance scrub-style jumps rather than the large rapid double-jumps that seem to trigger this, so it's not a clean progressive-negative result — just untested in an equivalent way.

Suggested repro: chain two or more very-large-distance seeks within 2-3s of each other, both directions, on both a progressive and an interlaced file.

[superuser404notfound]

Confirmed on both halves, and the residual is the same defect through the door round 1 did not close. Fixed on main in eade67c6 (merge 893a65fa), not in a release yet.

What round 1 left open. The seek generation moves when a seek is REQUESTED, because everything already in flight has to be invalidated at that point. The read position moves when the reposition RUNS, which since #254 is awaited off the main actor, tens of milliseconds later. All three of round 1's guards compare generations, so they close the door on a packet whose read started before the bump and leave it open for one read INSIDE that window: those bytes come from the position the seek left behind and they carry the NEW generation, which is every one of those gates' pass condition.

Why it lands in vLead and stays there. On a backward seek the stale frame's timestamp is PAST the target, so the skip threshold passes it and clears itself on the way through, and the frame is admitted to the renderer. The frontier is recorded at admission and it is a MAXIMUM, so no frame from the new position can lower it again: the cushion reads the seek distance until the next flush rather than for one sample. It also does not need a matching dpts jump, because a stale HIGH frame sorts to the tail of the reorder buffer and is never the one handed over, unlike round 1's stale LOW frame which sorted first.

One correction to the reading, and it points at the same place. The magnitude is not the previous seek's jump distance, it is the frontier the session was holding when the seek was issued, which is the previous target plus however long it played. That is why both numbers sit ABOVE the gap by about the same amount: 2301.93 against 2297.15 is 4.78 s, and 2474.81 against 2470.64 is 4.17 s. Round 1's correction ran the other way (short of the gap, because the reference was the last frame handed over rather than the frontier), and the pair of them is a good description of the two references.

The drop bursts are consistent with the same frame rather than with a second cause: clearing the skip threshold on its way through is what the frames between the landing keyframe and the target were being stopped by, so they reach the layer behind the re-anchored clock instead of being skipped. Worth watching whether the burst goes away with the reading on the retest, since that is the part I could not measure here.

FileB is not a counterexample, and this is not a progressive/interlaced split. The window opens on every seek. What makes it visible is a large BACKWARD seek, because only then is the stale timestamp past the target and through the threshold; a small scrub jump is exactly the case the threshold catches. So a session of short jumps reading clean is what the mechanism predicts.

The fix makes the window a state rather than an inference: open from the generation bump until that seek has both landed and re-anchored the clock. The demux loop parks on it (in the same park that already keyed on isPlaying, which a seek clears a few statements after the bump and which therefore left both that stretch and the whole landing reachable), and it discards anything a read took out of the window. A superseded seek does not close a window a newer seek is still inside.

The audio side of the same window is round 1's symptom by another door and closes with it: a packet enqueued after the landing but before the clock is re-anchored used to be measured against the pre-seek clock, and a lead the size of the seek reads as an exhausted one.

Measured, on a 3000 s fixture with twelve alternating large seeks two seconds apart, the window widened by a probe stall so that a seek reliably lands inside it: 5 to 9 packets per run entered the pipeline from a source that had not been repositioned yet, timestamps at the old position, and two of three runs took a clock pause for a rebuffer that was not happening. Zero of either on the fix, over the same runs. Without the probe the landing latency is unchanged, 59.7 ms against 60.7 ms over 24 seeks, so the park costs nothing measurable. One thing that measurement cannot show from here: on the synthetic H.264 and MPEG-2 fixtures the packet that got in never produced a frame from the old position, since the decoder had just been flushed and the packet was mid-GOP, so what is directly measurable on this end is the packet rather than the frame it becomes on your sources.

A retest on the next release closes this. The same seek chain is the right shape for it, and the FileI case is again the interesting one.

[superuser404notfound]

Released in 6.68.3 (67a2604). Both consumers are on it: Sodalite 15d021b2, AetherPlayer 24bcb2d.

What the retest should show on the same chain of large alternating seeks: no vLead sample carrying a seek distance, on any landing, and the frame-drop burst at those landings back to the size the smaller jumps produce. The FileI and FileJ patterns are the ones to repeat, since those are where it landed both times.