Live cutter wedges with zero audio packets on an mp2-stereo MPEG-TS under the FLAC bridge (regression 6.31.0 -> 6.47.0)

[Simpendaal]

What happened?

I played a live MPEG-TS channel whose audio is MP2 stereo. I expected the segment producer to keep cutting for as long as the source delivers, which is what 6.31.0 does on the same channel and the same origin. Instead 6.47.0 finalizes segments normally for about twenty seconds and then wedges the cutter with zero audio packets in its window, emits one 85 MB segment declared as half a second, and produces nothing after that.

The one deliberate behavioural difference between the two versions on this class of source is 6.32.0's move from E-AC-3 to FLAC for a bridged source of two channels or fewer. 6.31.0 reports decoding + EAC3 re-encode and plays for minutes; 6.47.0 reports decoding + FLAC re-encode and wedges.

Recovery afterwards behaves correctly on its own terms and cannot help, because there is nothing left to serve: #65 nudges, then skips stage 2 with "the producer is starved, not the consumer", and the item dies with AVFoundationErrorDomain/-11866. The viewer gets a thirty-second rebuffer, a few seconds of picture, and a second stall the session does not return fr

Steps to reproduce

Take a live MPEG-TS source whose audio is MP2 stereo at 48 kHz, two channels (mine is HEVC 3840x2160 at 50 fps, hvc1.2.4.L153, from an Xtream panel that answers with a 302 to a token-bearing media host).
Configure LoadOptions with the default audioBridgeMode (.surroundCompat) and load it as a live source on the native route.
Watch the HLSSegmentProducer log for about half a minute.
Segments seg-0..seg-16 finalize at 1.280 s each, then the no-cut watchdog fires with window video=1792 key=30 audio=0.
The same channel on 6.31.0, same host and same app build, plays for minutes with muxCuts climbing steadily (44, 71, 94, 117, 144 at t=30/60/90/120/150 s).

AetherEngine version or commit SHA

6.47.0

Host app

Custom / my own integration

Platform

tvOS

OS version

26.6

Device / chip

ATV 4k 3th gen

Playback path

Native AVPlayer

Source media (for playback bugs)

No response

Error codes / log lines

6.31.0, working:

[HLSVideoEngine] audio: codec=mp2 (bridge required), decoding + EAC3 re-encode [AudioBridge] init: mode=surroundCompat srcCodec=86016 sampleRate=48000 sourceChannels=2 encoderChannels=2 bitRate=256 kbps [HLSVideoEngine] prepared: codec=hvc1.2.4.L153,ec-3 resolution=3840x2160 fps=50.000

6.47.0, wedging:

[HLSVideoEngine] audio: codec=mp2 (bridge required), decoding + FLAC re-encode [AudioBridge] init: mode=surroundCompat encoder=flac srcCodec=86016 sampleRate=48000 sourceChannels=2 encoderChannels=2 bitRate=VBR (source=container, container=2, decoder=2) [HLSVideoEngine] prepared: codec=hvc1.2.4.L153,fLaC resolution=3840x2160 fps=50.000

[HLSSegmentProducer] no-cut stall: no segment finalized for 10s (packetsRead=3787, sinceFinalize=1792, rate=179.1pkt/s, cutter wedge); window video=1792 key=30 audio=0 foreign=0 videoPtsAdvance=0.0s; aborting the source read and exiting for host retune [HLSSegmentProducer] seg-17.m4s captured (85388914 B) [HLSSegmentProducer] live seg-17 finalized: start=21.740s dur=0.500s [HLSSegmentProducer] pump finished: reason=segmentStall packetsRead=3788 packetsWritten=2876 lastError=0 elapsed=11094ms [HLSVideoEngine] live segment cutter stalled (likely SSAI ad pod); requesting host retune to the server route

[AetherEngine] #65 re-engaging stalled AVPlayer (stall + 6s without fetches): nudge seek to 21.45s [AetherEngine] #65 stage-2 skipped: no segment finalized since the stall (producer still at seg18); the producer is starved, not the consumer; publishing liveSourceReset to host [NativeAVPlayerHost] #1 failedToPlayToEndTime AVFoundationErrorDomain/-11866 'Playback Stopped'

Both memprobe samples after the wedge read muxBytesMB=0 muxCuts=0, and the producer stays at seg18 for the rest of the session.

Anything else

What this report does not establish: the same line reports videoPtsAdvance=0.0s, and a change of audio encoder does not explain a video timeline that fails to advance across 1792 packets, so a second factor may be present. The origin is also independently unreliable. Measured with curl outside any player it closes the connection by itself after ten to fifty-five seconds, and it answers 401 to a reused token link, which is the same shape as the 302-to-a-one-slot-host origin in 6.36.0. Two other players buffer on this channel as well, roughly once every few minutes, so a source-side dropout coinciding with the wedge cannot be excluded from this trace alone. The control that would settle it, 6.47.0 against a channel whose audio is stream-copied AAC and therefore never enters the bridge, has not been run.

On the workaround: AudioBridgeMode offers no way back for this source, since .lossless is FLAC unconditionally and .surroundCompat returns FLAC for any source of two channels or fewer, so a host that hits this has to pin back.

[superuser404notfound]

The wedge is real and it is fixed in main (6997c884). It is not the audio encoder, though: measured below, 6.31.0 wedges identically on the same input while running the EAC3 bridge.

What the trace already proves

Three numbers in the report agree on one mechanism.

videoPtsAdvance=0.0s was printed at all. The watchdog suppresses that field entirely when no packet in the window carried a usable PTS, so the packets did reach it with timestamps. 1792 ticks on the 90 kHz MPEG-TS axis is 0.0199 s, which prints as 0.0. That is one tick per packet, exactly.

One tick per packet is the engine's own signature. A packet that arrives with neither DTS nor PTS was repaired to lastValidDts + 1. That satisfies the muxer's monotonic invariant and nothing else: on a 50 fps source it claims 11 microseconds of presentation time for a whole 20 ms frame.

packetsWritten=2876 says nothing was dropped on the way. 21.74 s at 50 fps is 1087 frames, and 1087 + 1792 is 2879, so essentially every packet read was muxed. That also rules out the alternative reading: had the source been repeating a frozen PTS of its own, the monotonic-DTS guard would have dropped those packets and the two counters could not line up.

The live cutter's clock IS that timestamp. It opens a segment at a keyframe's PTS and cuts at the next keyframe whose PTS is the cut target past the open segment's start (0.5 s on the fastZap profile, which is also where dur=0.500s on seg-17 comes from: no next segment ever recorded a start, so the finalize fell back to the target). With the clock advancing 11 microseconds per frame, none of the 30 keyframes in the window could reach 0.5 s between them, every one was declined, and 35.8 s of media went into one 85 MB fragment.

So the second factor you flagged is the whole of it: the source stopped carrying timestamps, the engine replaced them with something monotonic that is not a presentation time, and the cutter starved on its own clock. Recovery afterwards then read the situation correctly, as you say, and had nothing left to serve.

The FLAC axis, measured

Fixture: 50 fps HEVC plus mp2 stereo at 48 kHz in MPEG-TS, whose video PES headers stop carrying PTS/DTS at t=20 s. The timestamp bytes become legal PES stuffing, so PES_header_data_length and every byte offset downstream are unchanged and only the timestamps go missing. Served over loopback at 2.6x real time.

arm	bridge	segments finalized	outcome
6.31.0	decoding + EAC3 re-encode	5, last at 19.2 s	no-cut stall ... cutter wedge, retune
6.47.0	decoding + FLAC re-encode	5, last at 19.2 s	same line, same window
main 6997c884	decoding + FLAC re-encode	12, through 52.8 s	no stall, playhead at 39.6 s and still moving

6.31.0 and 6.47.0 are the same wedge to the packet: window video=998 key=16 audio=831 foreign=0 videoPtsAdvance=0.8s in both. The anchor + 1 repair is in the 6.31.0 source as well, so the version pair in your run separates two sessions, not two encoders. The one thing the encoder choice cannot do is change what the demuxer reads, and both audio=0 and the missing timestamps are read-side facts, upstream of the bridge.

What changed

A packet with no timestamp of its own now advances by a plausible frame interval instead of one tick: the demuxer's own duration for that packet, else the last genuine inter-packet delta the stream showed (learned from genuine timestamps only, never fed back from a repaired one, and never from a delta past a second, which is a program boundary rather than a cadence), else the frame duration the producer already carries for the last trun sample, else the single tick for a stream that has never carried a usable timestamp at all. On the fixture the learned stride is 1800 ticks, which is 0.0200 s at 50 fps.

The DTS-only case keeps its minimal bump, because there PTS is real and must not be crossed.

Two things that were silent are now readable, which is what made this trace hard to close from the outside:

• the repair says once per pump that the source stopped carrying timestamps and what was put in their place;
• the no-cut stall line reports how many packets in its window carried a synthesized timestamp (synthesizedTs=N), so videoPtsAdvance can be read as a statement about the source rather than about the engine's own repair.

What this does not fix

If the source really stops delivering audio for that long, the producer now stays alive and the playlist keeps growing, but a declared audio track that stops receiving samples can still park AVPlayer. Measured on the variant of the fixture that drops the audio PID outright: producer healthy through 12 segments, playhead parked at 21.2 s. So the picture continuing depends on the audio coming back. If your channel shows that shape after the fix, it is worth its own issue with the fragment ledger, because the answer there is a different one (re-init without the track, or a discontinuity).

On the workaround

Your reading of the mode table is right, and it is deliberate rather than an oversight: .surroundCompat resolves to FLAC for a source of two channels or fewer because there is no surround to carry, its EAC3 output would be lossy where FLAC is lossless, and a Dolby bitstream on a route that can only pass it through was measured silent in #395. Pinning back would not have avoided this wedge in any case, per the 6.31.0 arm above.

What would settle the source side

Two lines and one run, and none of them need a new build:

1. the reader's own lines around the wedge (gen=, reconnects=), since the origin closing on its own after ten to fifty-five seconds is the obvious candidate for what took the timestamps away, and a mid-stream reconnect is visible there;
2. whether a live PTS discontinuity detected line appeared before the stall;
3. the control you named: 6.47.0 on a channel whose audio is stream-copied AAC. With the mechanism above it should wedge too if that channel's source drops timestamps, and play if it does not, which is the discriminator between "this origin" and "this class of origin".

[superuser404notfound]

Released in 6.48.0 (0c3bb669), alongside a separate reader-handover fix. The two new lines to watch on a source that goes timestamp-less are the once-per-pump source stopped carrying timestamps ... synthesizing at N ticks/packet and synthesizedTs=N in the no-cut stall window, so videoPtsAdvance can be read as a statement about the source rather than about the repair.