BDREMUX plays for 28 seconds and stops, from any starting point

[1096bimu]

What happened?

Aether-Godzilla-Diagnostics.zip

Observed failure
At 2026-09-19T13:08:33.739Z NativeAVPlayerHost #1 reports failedToPlayToEndTime, CoreMediaErrorDomain -19602. The nearby request is seg8.mp4. The local server then reports errno=32 (broken pipe).
At 13:08:36.902Z automatic item-death recovery reloads at 28.77 s.
At 13:08:36.964Z replacement item #2 fails immediately with the same -19602. AVPlayer errorLog is nil.
Apple system logs report fpfs_BytePumpFn error -19602 from manifold-substream 0 role 0. VideoToolbox invalidates its session after 695 decoded frames, zero dropped frames, and 28850 ms duration.
The segment producer had reached segment 18/source approximately 72 s, so this is not simply a producer that stopped reading at 28 s. Subsequent backpressure PARK messages occur after the consumer failure.

Interpretation / remaining isolation
The failure is in the native AVPlayer / local-HLS path. These logs do not prove whether the triggering defect is video sample timing/packaging, bridged audio, input metadata, or an Apple parser issue. Do not infer a public meaning for undocumented error -19602.

Excuse me this is the first time I'm reporting anything on Github and I honestly don't know much of how this works but there seems to be an issue with the engine when playing a particular blue-ray remux file, it just stops after exactly 28 seconds of playing from any point.
It happens on AetherPlayer MacOS your latest build.
It also happens on my own VisionOS app using AetherEngine.

I don't really know how this works so the report was prepared by Codex. It is probably not the audio stream because the exact same thing happens with the other stream as well. Selecting or not selecting subtitle tracks did not make any difference either.

This file plays perfectly in other players like MPV, and I have so far not found the same issue with any other of my files.

Steps to reproduce

File is not available to share, media info is included in zip package.
playing it from any point and it stops after 28 seconds of playing.

AetherEngine version or commit SHA

7.6.0

Host app

AetherPlayer

Platform

macOS

OS version

MacOS 27, VisionOS 27

Device / chip

M4 Max, M5

Playback path

Native AVPlayer

Source media (for playback bugs)

No response

Error codes / log lines

Anything else

No response

[superuser404notfound]

Thanks for the report, and thanks for the diagnostics bundle. That folder was genuinely useful, the system log capture in particular. It narrowed this down a long way.

What the logs already establish

The failure is not a timeout, a stall or a producer that stopped reading. It is one specific artifact being rejected by Apple's fMP4 parser, and both captured sessions fail on the same one: seg8.mp4, the ninth segment.

• Session 1: seg8.mp4 is requested, the byte pump hands the first 131072 bytes to the parser, and -19602 is signalled 4 ms later. The errno=32 broken pipe on the server side arrives 18 ms after that, so it is the consequence of the client hanging up, not the cause.
• Session 2 (a fresh open, no seek): identical, same segment index, error 8 ms after the first 128 KiB.
• The stage-2 reload then re-requests seg8.mp4 and dies on it again, which is why recovery never takes.

So the parser rejects seg8 inside its first 128 KiB, which is the styp plus moof region, before any picture data matters. The segment itself was finished and cached 29 seconds before it was ever requested (#65 ledger seg-8 at t+0.7 s, GET /seg8.mp4 at t+29.0 s), and by then the producer had already completed through seg-17. Nothing was still being written.

That also explains the "28 seconds from any position" shape: it is not 28 seconds of anything, it is however long the first eight segments take to play out.

One engine-side anomaly I can see, not yet proven to be the cause

Every segment in that session opens about 0.751 s later than the playlist says it does (drift=0.751s on nearly every #65 ledger line). At the moment of failure the video samples already buffered reach 34.034 s while seg8's first sample sits at 33.492 s, so seg7 and seg8 overlap by roughly half a second. On a local 4K HEVC fixture here the same code path produces perfectly contiguous segments (32.0000 -> 36.0000, 36.0000 -> 40.0000, zero gap on both tracks), so that overlap is specific to what this file's keyframe index looks like, and it is the best lead I have.

I cannot confirm it without seeing the actual bytes, which is what the first request below is for.

What would settle it

1. The first 512 KiB of the segments

The moof sits at the very front of each segment, so a small head of each file is enough, no picture content of consequence and nothing large to upload. Start playback, let it fail, leave the app open, then run this in Terminal:

OUT=~/Desktop/ae561-moof; mkdir -p "$OUT"
LOG=~/Library/Containers/de.superuser404.AetherPlayer/Data/Library/Logs/AetherPlayer/AetherPlayer.log
BASE=$(grep 'serving on http' "$LOG" | tail -1 | sed -E 's|.*(http://127\.0\.0\.1:[0-9]+/[0-9a-f]+/).*|\1|')
echo "$BASE"
curl -s "${BASE}init.mp4" -o "$OUT/init.mp4"
curl -s "${BASE}media.m3u8" | head -40 > "$OUT/media-head.m3u8"
for n in 0 1 2 3 4 5 6 7 8 9; do
  curl -s "${BASE}seg$n.mp4" 2>/dev/null | head -c 524288 > "$OUT/seg$n.head.bin"
done
cd ~/Desktop && zip -r ae561-moof.zip ae561-moof

The app has to still be running when this runs, because the local server lives and dies with the playback session. If echo "$BASE" prints nothing, the session already closed, so reopen the file first.

That gives me every tfdt and trun for segments 0 through 9 and I can tell immediately whether seg8's sample table is malformed or whether its placement on the timeline is what Apple objects to.

2. One run started deep into the film

Both captures start producing at plan index 0, so they cannot separate "the content at source 32.7 to 37.4 s" from "always the ninth segment produced". Please open the file, seek to somewhere around 20 minutes, let it play, and capture the log with the same log stream command as before.

Segment numbers are global plan indices, so after a seek the producer anchors at some index N and the ninth segment it makes is segN+8, not seg8.

• Dies roughly half a minute after the seek, on the ninth segment fetched: the defect is structural and lives in the producer.
• Plays past it: the defect is in that one stretch of source content, and I go looking there instead.

3. A confirmation on the audio track

The note says the same thing happens with the other stream. Please confirm explicitly that this was the DD+5.1 E-AC-3 track selected in place of TrueHD.7.1.Atmos, because that track needs no bridge and rules out the TrueHD to E-AC-3 re-encode entirely.

One note on versions

7.8.0 is out, but the only change to the segment producer since 7.6.0 is the live recording tap from #560, and the muxer and the segment planner are byte for byte identical. It will behave the same here, so there is no need to update before capturing.

[1096bimu]

begging DD sound track.zip
beginning.zip
later.zip

I experimented more and decided it is definitely not a fixed 28 seconds into the play session, but specific places in the video, all throughout, and not evenly spaced, it's just the first problematic position is at 28 seconds. Some sections of the file can play for a few minutes without encountering a fault.

I've included capture of the beginning, and then another spot later int the video, as well as a capture of the beginning with the other soundtrack which doesn't seem to have made a difference.

[superuser404notfound]

That capture set settled it, and the run started deeper into the film was the decisive half. Thank you for taking the trouble with both.

What the bytes say

Parsing every moof in the three captures: in this stream almost no segment begins with a keyframe. The first random-access point sits 19 frames (0.792 s) inside the segment, with the IRAPs themselves 21 frames apart. It holds for seg1 through seg8 in the two runs from the beginning, and for seg393 through seg403 in the run from ~26 minutes, so it is not a property of one position. The only fragments that do open on a keyframe are the ones a producer re-anchor wrote.

That is the same thing the engine's own #412 line reports on every single segment of the first log: opens 0.751s below its first random-access point. A segment whose first sample is a dependent picture cannot start a decode run at all.

The sample tables themselves are fine, for the record: every trun sums exactly to its mdat payload, and seg8's Content-Length is exactly moof plus mdat. Nothing is truncated or malformed.

Why

The segment plan's boundaries ARE the container's index entries, and containers disagree about what an entry's timestamp means. A mov/mp4 sample table stores decode times. A Matroska Cue stores a presentation time. The segment cutter compared decode times against both, which is correct for mov/mp4 and wrong for any Matroska whose video carries composition offsets, meaning any MKV with B-frames.

On such a source no keyframe can ever reach its own boundary, because its decode time sits a composition offset below it. The cutter therefore never opens a segment on the keyframe the plan named. Audio, which is routed by boundary rather than gated on keyframes, opens the segment instead, and the keyframe stays in the segment before it. Every segment then starts mid-GOP.

That also explains the shape of the failure. While AVPlayer decodes THROUGH the segment boundaries, the previous segment supplied the reference frames and nothing is visibly wrong. The moment it has to start decoding FROM a boundary it finds no random-access point. Where that happens depends on the encode and on buffering, not on the clock, which matches the correction that it is specific places throughout the film rather than a fixed 28 seconds. It also explains why the stage-2 reload died immediately on the same segment.

Two things from the earlier analysis are now off the table: the seg7/seg8 overlap was a consequence of this, not a separate defect, and the question of whether it is "always the ninth segment produced" is moot, since the property holds for every segment.

The soundtrack observation is consistent too. The defect is on the video side of the cut, so swapping the audio track cannot change it.

Fixed

PR #578 makes the gate compare a packet on the plan's own axis, read from the container the demuxer actually opened. A keyframe then reaches its own boundary exactly, on either container. mov/mp4 sessions are unchanged byte for byte.

Reproduced and verified without the source file, on one HEVC stream muxed into both an MKV and an MP4 by stream copy, so the packets and timestamps are identical and the index stamping is the only difference:

	first sample of seg1 and up	first IRAP	isolated decode
MKV before	dependent picture	19 frames in	184 reference errors
MKV after	keyframe	0	clean
MP4, before and after	keyframe	0	clean

H.264 in Matroska turned out to be affected in exactly the same way, so this is a property of the container rather than of HEVC, and it reaches a good deal more than this one file. That it is also what AVPlayer answers with -19602 is the strong inference rather than something measurable from here, so a retest on the actual film is what would confirm it. There is no release carrying this yet; a note will follow here when there is, and the same fix covers the visionOS app, since it is the engine's own segment producer.

One unrelated thing the captures turned up: the first audio fragment carries baseMediaDecodeTime = 0xFFFFFFFFFFFFFF00, a negative value wrapped into an unsigned 64-bit field. It is being tracked separately and is not connected to this failure.

[superuser404notfound]

Released in 7.8.1.

• the segment cut on the container's own axis: 837402c0
• the bridged audio origin, which is why the TrueHD track's first fragment carried tfdt 0xFFFFFFFFFFFFFF00 while the DD+5.1 track started cleanly: 4bc856d6
• the boundary tolerance on a Matroska restart: 34037a76

AetherPlayer will pick it up in its next build. For the visionOS app, the pin is 7.8.1 (b89240af).

Retesting the film is what would confirm the reading: the expectation is that it plays through the places it used to stop at, rather than reaching them later. If it still stops somewhere, the two useful things are the same log stream capture as before plus the segment heads around the new failure position, since the structural test is now whether a segment opens on a keyframe, which those bytes answer directly.

Leaving this open for that.

[1096bimu]

it didn't fix the issue, I managed to clip out an example of exactly where it goes wrong, but MPV does play it without issue.
Then I discovered that using MKVtoolnix to remix this clip fixes the problem, even if no track has been changed.

I produced this absolute minimal clip which would produce the problem from Codex's diagnosis and confirmed it trips up AetherPlayer but not MPV.

aether-malformed-packet-evidence.zip

aether-mkvtoolnix-comparison.md

[superuser404notfound]

That clip is the whole answer, and the MKVToolNix observation was the thread to pull. Thank you for cutting it down that far, a 0.667 s file with one damaged packet and no audio and no subtitles is about as clean as a reproduction gets.

Confirmed here

Your minimal clip fails on 7.8.1 exactly as you describe, and it fails for a reason that has nothing to do with the segment boundaries #578 was about: one segment, opening on a flagged keyframe, no audio, no subtitles, and -19602 inside a second.

The diagnosis in your comparison file is right, and I can add why the two players disagree.

A sample in an mp4 video track is a run of NAL units, each one introduced by a big-endian length of the width the hvcC record declares, and a parser walks that run by addition. Your packet's sixth length field declares 384137139 bytes with 350873 left in the packet. From there:

• libavcodec logs Invalid NAL unit size (384137139 > 350873), skips that frame and plays on. That is mpv, and it is also this engine's own software path.
• Apple's fMP4 parser has no such recovery. It answers the whole SEGMENT with CoreMediaErrorDomain -19602, the session ends, and the reload lands on the same segment and dies again.
• MKVToolNix drops the unparsable tail on remux, which is exactly why a remux with no track changed fixes the file.

That is also the answer to your correction about the timing. It is not 28 seconds of anything and not a fixed spacing, it is one damaged sample, and playback dies at whichever position AVPlayer first has to decode across one. Some stretches have none and play for minutes.

I ran your own clip through the decoder here for the record, and the one packet is the only one in it that libavcodec refuses.

Fixed

Merged as 729ccafd (4fc2b72f). The session muxer now walks each video sample's NAL chain before the write and cuts it at the last complete unit, which is the same bytes MKVToolNix would have written. A healthy sample is untouched, and the prefix width is read from the configuration record rather than assumed, so H.264 and the narrower framings are covered too.

Measured on a fixture pair that differs in four bytes, one rewritten length field in an 8 s encode, so the healthy source is a real control arm:

	healthy	damaged
before	plays	-19602 at once
after	plays, nothing cut	plays, one cut logged

And on your clip: -19602 at once before, plays through after, cutting the packet from 505491 bytes to 154614, which is byte for byte what your remux produced.

No release carries this yet. There will be a note here when there is, and the same fix covers the visionOS app since it is the engine's own muxer.

What would confirm it on the film

The film itself, unremuxed, on that build. The expectation is that it plays through the places it used to stop at. If a sample gets cut you will see a line like

[MP4SegmentMuxer] #561 video sample at dts=... carries an incomplete NAL chain: N bytes, M of them complete

in the log, and a frame with a missing slice is possible at that instant, a brief visible artifact rather than a stop. If it still stops somewhere, the same log stream capture plus the segment heads around the new position is what answers it, since the structural question is now whether the sample itself parses.

One separate note, since your capture turned it up: the engine dying outright on a single unparsable segment, with the automatic reload landing straight back on it, is its own weakness. It does not arise once the sample is cut, so it is not addressed here, but it is written down.

[superuser404notfound]

Released in 7.9.0.

• the sample cut at its last complete NAL: 729ccafd
• the software path as the rung under a refused session: 7cb09e49

The second one is the part about your capture that was still open: a single segment AVPlayer refuses used to end the session, and the automatic reload landed straight back on it, which is why the recovery in your log died 62 ms after the first item. A CoreMedia failure is now handed to the engine's own decoder instead, which rebuilds the session at the playhead and decodes the file with libavcodec. So even where a damaged sample turns up in a shape the cut does not reach, the session should keep playing rather than stop.

Measured before shipping, on a 40 s fixture with one damaged sample at 20 s: it used to play to 15.87 s and die there for good; it now dies at the same place and comes back on the software path at 12.00 s, playing through the damaged sample to the end of the file.

AetherPlayer will pick this up in its next build. For the visionOS app the pin is 7.9.0 (bc50c3da).

Retesting the film is what would confirm the reading. If it plays through the places it used to stop at, that is the cut doing its work. If you see a brief rewind of a few seconds and then playback continuing, that is the second rung, and the log line to look for is

[AetherEngine] #561 AVPlayer refused the media (CoreMediaErrorDomain/-19602) at ...s; rebuilding this session on the software path

Leaving this open for that.

[1096bimu]

confirmed the original movie now plays without issues.

the small clip I made plays with a bunch of green artifacts but nothing abnormal in the original file.

[superuser404notfound]

Thank you for confirming, and for the whole run of captures. The minimal clip in particular is what turned this from a guess into two measured defects.

The green on that clip is expected, and it is worth writing down why it appears there and not in the film, since the difference is a property of the clip rather than of the fix.

Parsing the clip's samples: every picture in this encode is carried as 8 slice NAL units. The damaged sample is not the keyframe, it is a trailing picture at presentation time 0.375 s, and of its 8 slices only 3 arrive before the length field goes bad. The cut keeps those 3 (154614 of 505491 bytes) and drops the 5 that were never readable. So the decoder is handed a picture whose lower region genuinely never arrived, and an undecoded region of a picture buffer is what shows up as green.

What is special about the clip is that its only random-access point is its first packet. Nothing after 0.375 s resets the reference chain, so the hole is carried to the end of the file, and roughly the last third of a 0.667 s clip inherits it. In the film the random-access points sit 21 frames apart, about 0.9 s at this frame rate, so the same damaged sample is written over well inside a second, in motion, at 24 fps. That is why the film looks clean while the clip does not.

The alternative would be to discard the sample outright, and that is worse: the trailing picture disappears entirely and everything referencing it has nothing to predict from. Cutting at the last complete unit hands over the part of the picture that actually exists. libavcodec takes the other route, dropping the frame and concealing it from the previous one, which can look tidier while carrying less real picture data, and that is the difference you saw against mpv.

Either way the missing five slices are damage in the source file itself. No player can recover bytes that are not there, and MKVToolNix removes exactly the same tail, so a remuxed copy of that clip will show the same thing.