Live 1080p50 H.264 TS: intermittent freezes, AVPlayer reports -12888 (playlist unchanged > 1.5 × target duration) and client "running thin"

[Simpendaal]

What happened?

On live MPEG-TS streams (H.264 1080p50, AAC), playback through AetherEngine freezes briefly every so often; the host OSD pops up because the player drops out of the playing state for a moment. The same stream plays without any issue in KSPlayer (a 34 min session in the same log: 0 dropped frames at 49.99 fps) and in QuickTime. VLC on Mac shows similar freezes.

In the log, the live HLS producer cuts segments against a 0.5 s cut target, but the actual segments come out at 1.0 to 2.4 s (GOP-bound). TARGETDURATION is then sealed at 1 to 3 s. AVPlayer repeatedly reports CoreMediaErrorDomain -12888 ("Playlist File unchanged for longer than 1.5 * target duration") on the local media.m3u8, and #524 fires 287 times with only about 1.5 to 2 s of fetched runway. At the same moments AVSampleBufferVideoRenderer toggles readyForDisplay NO → YES, which matches the visible freezes.

Steps to reproduce

Play a live H.264 1080p50 MPEG-TS stream (sample capture available, see below) through AetherEngine on tvOS.
Watch for a few minutes.
The picture freezes briefly at irregular intervals; -12888 and #524 show up in the log at the same moments.

AetherEngine version or commit SHA

7.17.1

Host app

Custom / my own integration

Platform

tvOS

OS version

27

Device / chip

Apple Tv

Playback path

Native AVPlayer

Source media (for playback bugs)

Live MPEG-TS over HTTP, H.264 High@4.2 1920x1080, 50 fps, SDR, fieldOrder=1, AAC ADTS (stream-copied). A 53 MB TS capture of the stream is available on request.

Error codes / log lines

[HLSSegmentProducer] init OK (baseIndex=0, segments=0, targetDur=0.500s, srcVideoTb=1/90000) audio=stream-copy inTb=1/90000
[HLSVideoEngine] live TARGETDURATION sealed at 1s (holdback 3.000s): max EXTINF 1.000s, 1.5 x cut target 0.750s, no measured floor (segments are cut here, not ingested)
[HLSSegmentProducer] live seg-67 finalized: start=68.040s dur=1.120s
[NativeAVPlayerHost] #9 errorLog code=-12888 domain=CoreMediaErrorDomain uri=http://127.0.0.1:52900/.../media.m3u8 'Playlist File unchanged for longer than 1.5 * target duration'
[AetherEngine] #524 the client is running thin: it holds 1.48s of fetched runway, playhead 5421.82s against a seekable edge of 5436.58s (which already carries the holdback)

-12888 appeared 188 times over three sessions; #524 appeared 287 times.

Anything else

The TARGETDURATION sealed at 1 s is exceeded by later segments (for example 1.120 s), and with a 0.75 s staleness basis the playlist can easily look "unchanged" to AVPlayer whenever a GOP runs long.

[superuser404notfound]

Thanks for the detailed log, the seal line pointed straight at it. Reproduced on the Mac against current main (7.23.0), and the fix is up as #676.

What happens. Under .fastZap the engine cuts at every keyframe past 0.5 s, so each segment is one whole source GOP. TARGETDURATION is sealed from the first window and has to stay fixed for the session. On your stream that window held three 1.000 s GOPs, so it sealed at 1 s with a 3 s holdback and no headroom at all. Your GOPs are not regular (1.0 to 2.4 s in the log), and every longer one then:

• exceeds the sealed value (EXTINF 2.4 rounds to 2, above TARGETDURATION 1),
• leaves the playlist unchanged for longer than AVPlayer's 1.5 x TARGETDURATION patience while the cutter waits for the next keyframe (your -12888),
• makes the engine read the source as stalled (An unsatisfiable blocking reload starves a client whose cache already holds its runway #446) and leaves the client on 1.5 to 2 s of runway (your A bursty upstream eats the join cushion, and one minute in the session rebuffers once #524 lines).

.standard never ran into this because its 4 s cut target already carries 50% headroom. Under fastZap that headroom collapsed to nothing.

The fix. When the engine cuts the segments itself under fastZap, the seal now takes ceil(1.5 x the longest GOP seen). A 1 s GOP stream serves TARGETDURATION 2 with a 6 s holdback, the same values you saw on your origins back in #195. Ingested HLS segments and .standard are unchanged. The seal line now names the new term, so the log shows 1.5 x max EXTINF 1.500s (each segment is one whole GOP).

Measured with a synthetic 50 fps TS using the same GOP pattern (1.0 / 1.12 / 2.4 s), two runs each. Before: sealed at 1 s, a stall on every run, and macOS AVPlayer rejected the playlist outright. After: sealed at 2 s, no stalls, no rejections. The join moves by about 0.2 s. The one real cost is that fastZap now plays about 6 s behind the live edge instead of 3 s.

One request: could you share the 53 MB capture you mentioned? I'd like to run the fix against your real GOP distribution before releasing it, since a stream that opens with 1 s GOPs and later runs GOPs longer than 3 s would still outgrow a seal of 2. Any file host works, or a private link by email if you prefer.

[Simpendaal]

Thanks for the detailed log, the seal line pointed straight at it. Reproduced on the Mac against current main (7.23.0), and the fix is up as #676.

What happens. Under .fastZap the engine cuts at every keyframe past 0.5 s, so each segment is one whole source GOP. TARGETDURATION is sealed from the first window and has to stay fixed for the session. On your stream that window held three 1.000 s GOPs, so it sealed at 1 s with a 3 s holdback and no headroom at all. Your GOPs are not regular (1.0 to 2.4 s in the log), and every longer one then:

• exceeds the sealed value (EXTINF 2.4 rounds to 2, above TARGETDURATION 1),
• leaves the playlist unchanged for longer than AVPlayer's 1.5 x TARGETDURATION patience while the cutter waits for the next keyframe (your -12888),
• makes the engine read the source as stalled (An unsatisfiable blocking reload starves a client whose cache already holds its runway #446) and leaves the client on 1.5 to 2 s of runway (your A bursty upstream eats the join cushion, and one minute in the session rebuffers once #524 lines).

.standard never ran into this because its 4 s cut target already carries 50% headroom. Under fastZap that headroom collapsed to nothing.

The fix. When the engine cuts the segments itself under fastZap, the seal now takes ceil(1.5 x the longest GOP seen). A 1 s GOP stream serves TARGETDURATION 2 with a 6 s holdback, the same values you saw on your origins back in #195. Ingested HLS segments and .standard are unchanged. The seal line now names the new term, so the log shows 1.5 x max EXTINF 1.500s (each segment is one whole GOP).

Measured with a synthetic 50 fps TS using the same GOP pattern (1.0 / 1.12 / 2.4 s), two runs each. Before: sealed at 1 s, a stall on every run, and macOS AVPlayer rejected the playlist outright. After: sealed at 2 s, no stalls, no rejections. The join moves by about 0.2 s. The one real cost is that fastZap now plays about 6 s behind the live edge instead of 3 s.

One request: could you share the 53 MB capture you mentioned? I'd like to run the fix against your real GOP distribution before releasing it, since a stream that opens with 1 s GOPs and later runs GOPs longer than 3 s would still outgrow a seal of 2. Any file host works, or a private link by email if you prefer.

https://wormhole.app/LKmREK#yHrQ6nuXzM1PlzDG4fgNTw

[superuser404notfound]

Released in 7.23.1 (0d3dc68). A retest on your stream would be great; the TARGETDURATION seal line should now read sealed at 2s with the 1.5 x max EXTINF term, and -12888 / #524 should be gone or rare. The capture is still welcome if you can share it.

[superuser404notfound]

Thanks for the capture, and sorry: the link was in the quote reply and I missed it when I posted the release note above.

I ran it through aetherctl live --fast-zap --realtime --preroll 0 on 7.24.0 (the capture looped as a 1x origin, 150 s, two runs):

• GOPs in the capture: 103 keyframes, the longest GOP is exactly 1.000 s, and the scene cuts in between go as short as 0.04 s. Under fastZap that gives segments of 0.54 to 1.48 s.
• Seal: sealed at 2s (holdback 6.000s) on both runs, with the new 1.5 x max EXTINF term in the line. The later candidate was 3 s, but no segment ever came close to breaking TARGETDURATION 2 (max 1.44 s).
• Playback: no -12888, no A bursty upstream eats the join cushion, and one minute in the session rebuffers once #524 line, no restarts, VERDICT: live playing on both runs, including across the loop point. The only wait was one of 0.1 to 0.2 s about 5 s after the join, which is the shallow bounded start that fastZap trades for the quick join, not this defect.

One thing the capture does not contain: the 2.4 s EXTINF from your original log. Its first three segments are 1.12 / 0.64 / 1.0 s, so even 7.23.0 would have sealed this window at 2 s, and no GOP in it is longer than 1 s. So the long segments in your session came from a stretch of the stream this capture does not cover. My guess is a keyframe lost in transport (a damaged IDR merges two GOPs into one segment, and 1.0 + 1.44 is exactly the shape of a 2.4), but that is a guess from the numbers, not something I can see here.

What would settle it is a retest on 7.23.1 or later: the seal line should read sealed at 2s with the 1.5 x max EXTINF term, and -12888 / #524 should be gone or rare. If a later candidate line then shows a value above 3, or a segment's EXTINF goes past 3 s, please post the log from that stretch, because that is the case a seal of 2 cannot cover.