Software-path SD MPEG-2 (PAL 25i): intermittent brief picture glitches with no engine-log signature — first seen on 6.5.3, unchanged on 6.5.6

[rrgomes]

On a 1979 SD television episode (MPEG-2, PAL source, 25 fps interlaced → 50 fields/s after deinterlace, software decode; ~4.5 GB file, local PMS), playback shows several brief visible glitches/pauses per couple of minutes. What makes it report-worthy is the silence around it: our 4 s stall detector never fires, there are no stall/nudge/error lines, DisplayCriteria is correct (content 25.000 → panel 50.000 Hz), and the transport is idle (the pump opens one 32 MB window per ~30 s; no starvation, no reconnects). Renderer cadence holds a steady ~50 enqueues/s throughout; isReadyForMoreMediaData=false is pinned from enqueue #8 onward, which may just be a healthily-full pipeline — if so, we have no signal at all coinciding with the visible glitches.

The asset has been part of our regular per-engine gate pass for months and was clean through the 6.3/6.4.0-era engines (we skipped the pass for 6.4.4, so the window is between our last clean pass and 6.5.3; 6.5.4's pump QoS step-down didn't change it, so #286 isn't the mechanism). AppleTV14,1, tvOS 26.5, native output.

Happy to run any diagnostics you'd like enabled, or test intermediate revisions. We see the software path's enqueued-frame count just merged on main (#288) — if a presented/dropped split, or presentation timestamps on the software path (the #260 analogue), is feasible, that would let us catch these moments in the act. We also noticed the post-6.5.6 SAR/decoder work (#290) touches container-declared-PAR handling for exactly this content class (anamorphic SD PAL) — happy to retest on main or the next release if that could interact.

[rrgomes]

The glitch signature is found: every visible stutter coincides with an [AVIOReader] detour fill on the direct-URL pump path. The picture defect is IO-timing, not decode.

New evidence since filing, on 6.6.0 (also reproduced on 6.5.3/6.5.6):

• The glitches are deterministic by content position — same places on every linear replay.
• They manifest as a stutter/jump, not pixel corruption.
• They reproduce identically under both deinterlace engines (yadif_videotoolbox hardware graph and the CPU bwdif fallback via LoadOptions.deinterlaceMode = .software) — confirmed from the [Deinterlace] engaged [...] lines — which also rules out the field-rate PTS contract, since the bwdif leg ran mode=send_frame.
• The source is clean on every axis we could measure: a full-file ffmpeg decode emits zero warnings; video PTS is a perfect 40 ms cadence across all 135,752 frames (no gaps, no duplicates); audio PTS equally continuous; every frame uniformly interlaced TFF; no repeated/blended fields at act boundaries. (Asset: a ~90-minute 720×576 PAL 25i MPEG-2 main-profile MKV, ~6.7 Mbps mux, AC-3 audio, played as a direct URL off the LAN.)

The correlation run: linear playback with a user pause tapped at each perceived glitch. Every mark lands 0.3–0.6 s (reaction time) after an AVIOReader event, and every such event in the window has a mark (one missed):

pump event (content time)                        pause mark
gen=2 rotation 30.8s + detour fill ~31.3s        31.3
detour fill ~36.0s   (5s after a resume)         36.2
gen=3 rotation 70.7s + detour fill ~71.4s        71.6
detour fill ~79.9s                               (not noticed)
detour fill ~111.6s                              111.7
detour fill ~116.2s  (5s after a resume)         116.7
detour fill ~152.0s                              152.0

The main-sequence marks sit 40.2 ± 0.2 s apart — exactly one 32 MiB pump generation at this file's 0.798 MiB/s mux rate. The two off-sequence marks each follow a pause-resume by ~5 s.

Why it shows on screen: the software path runs frameAhead=0.00s (per memprobe), so a read-path block of more than a frame interval is visible, and a 4 MiB detour fill is ~100 ms even at LAN rates. Why this class of content: high-bitrate SD means a rotation every 40 s; our ~1 Mbps AV1/VP9 items rotate every several minutes and are rarely caught in the act.

Happy to send the full session log (pump lines + pause marks on one timeline), the ffmpeg/ffprobe scan outputs, or run an instrumented build. If it's useful, the obvious directions from out here: detour fills serviced off the blocking read path, retaining the window tail across a generation rotation, or a few frames of queue depth on the software path — but you know this code far better than we do.

[superuser404notfound]

That correlation run found it. The stutters are the read path paying for bytes the origin had already delivered, and the mechanism is one line in the reader.

What happens at each rotation. A bounded range ends, and the #220 frontier refill opens the next one while data is still resident ahead of the read position, exactly so the boundary is not a stall. startPersistentConnection then reset the window start to that frontier and dropped the window with it, up to winLowWater (8 MB) of delivered but undrained bytes. The very next read therefore sat below the window start, took the backward branch, and pulled those same bytes back over the network in 4 MB detour blocks, on the demux read thread. That is the detour fill line you marked, and there are two of them per boundary.

Why it needed your kind of content to show. It only appears when the consumer is slower than the transfer, which is what playback is: the range completes long before the window drains, so the refill fires with the full low-water amount still resident. A test that reads flat out drains the window as fast as it arrives, reaches the boundary with nothing undrained, and sees nothing, which is why the existing #220 coverage stayed green through this. Your 6.7 Mbps SD source brings a 32 MB boundary around every 40 s, which is your 40.2 s spacing; a 1 Mbps item rotates every several minutes. And your reading of frameAhead=0.00s is the amplifier: the software path has no read-ahead to absorb a blocked read, so ~100 ms of detour fetch is a picture stutter rather than an invisible hiccup. On the native path AVPlayer would have swallowed the same event.

Both of your off-sequence marks fit the same mechanism. A pause fills the window to the hard cap, which ends the connection on purpose, and the re-request after the resume ran through the same window-dropping path; one 4 MB block at your mux rate is 5.0 s, which is the offset you measured.

Reproduced and fixed. PR #302. A continuation, meaning a request that begins inside the resident window or exactly at its end, now keeps its window instead of resetting the start to it. The witness drives a real HTTP origin with a paced consumer across a boundary and asserts that no requested range overlaps another. Before the fix the origin log reads

bytes=0-20971519          initial range
bytes=20971520-54525951   frontier refill
bytes=12582912-16777215   re-fetch
bytes=16777216-20971519   re-fetch

Not released yet, so nothing to retest against a tag today. When it goes out, the thing to look for is the absence of [AVIOReader] detour fill during linear playback: on a source with no backward seeking there is now no reason for a single one to appear, so any that survive would be a second mechanism rather than a residual of this one.

Worth saying plainly: the report class here was "no signature at all", and it was correct. The engine logged the cause on every occurrence and I had no line that connected a detour fill to a picture defect. Your pause-mark timeline is what made the connection, and the ffmpeg and PTS scans are what let me stop looking at decode.

[superuser404notfound]

Released as 6.6.4 (b58c8428, merged in 0d6d3569). Both consumers are bumped, so a Sodalite or AetherPlayer build from main carries it.

The retest that would settle this is the same asset on the same rig, watched for the same thing: on a source with no backward seeking, [AVIOReader] detour fill now has no reason to appear at all during linear playback, so the cheapest check is whether a single one survives. If none do and the glitches are gone, this is closed. If none do and a glitch remains, that is a genuinely separate mechanism and worth its own trace rather than a reopen of this one.

One correction to my previous comment, since it matters for what you measure next. I repeated your reading of frameAhead=0.00s as the software path having no read-ahead. That number cannot carry the claim: frameAhead is activeProducerShiftSeconds - playlistShiftSeconds, the #49 producer-shift fold on the native path, and it is hardcoded to 0 on software and audio. It is 0 there whether the cushion is 40 ms or 2 s.

What is true is narrower and is now #303: the software path back-pressures purely on AVSampleBufferVideoRenderer.isReadyForMoreMediaData, with no target depth of our own and nothing that reports the depth it actually had. So the amplifier I described is plausible and matches what you saw, but it is unmeasured rather than established, and the presented/dropped split you asked for is tracked there.

[superuser404notfound]

One addition for whenever the retest happens, since it landed an hour after the fix: 6.7.0 puts the missing number in the memprobe line.

swFrames=753 swAhead=0.26s swDropped=187/749 swDelay=0.00s

swAhead is seconds of decoded video queued ahead of the clock on the software path, swDropped and swDelay are the renderer own metrics, which unlike anything we count ourselves include frames dropped for missing their display deadline. On a native session the three fields are absent rather than zero.

So the retest can now answer the amplifier question directly instead of leaving it as my plausible story: if a stutter survives on 6.7.0, swAhead at that moment says whether the cushion was thin, and swDropped says whether the display actually dropped anything. If it does not survive, the same fields are still worth one line from a healthy run, because nobody has yet seen what this path holds in the steady state on real hardware. My own figure came from a headless harness and is not worth much.

6.7.0 also carries a contributed change to disc-image probing on custom readers, which does not touch your path (direct URL, not a custom IOReader).

[rrgomes]

Retested on 6.7.0, same rig, same asset: the glitches are gone. A full linear pass over every previously-marked position showed none on screen, and the session log has pump generations rotating on the same 40 s cadence with zero [AVIOReader] detour fill lines — the cheapest check comes back empty. Post-pause resumes are clean too.

The steady-state line you asked for, from real hardware (3rd-gen Apple TV 4K, LAN, same source):

swFrames=9034 swAhead=0.36s swDropped=8/9030 swDelay=0.00s

swAhead held 0.34–0.36 s across sessions — about nine frames of cushion at 25 fps — with drops in the tenths of a percent. This closes the issue from our side; thanks for the fast turnaround and the frameAhead correction.

One heads-up, deliberately not a reopen per your note: our seek-landing telemetry moved across the same upgrade window on the native path (median ~0.26 s → ~1.2 s on a DV-P7 title, ~0.14 s → ~0.40 s on a 4K HEVC title; software-path seeks unchanged at ~0.1 s). We're pinning back to 6.6.0 on one box to confirm causality and will file separately with data if it holds.