The plan boundary carries its container's axis, and two things that followed from it (AE#561)

[superuser404notfound]

Three commits, all from the AE#561 investigation. The first is the reported defect, the other two are what the same question turned up next to it.

1. A plan boundary is compared on the axis its container stamped

A keyframe-aligned plan's boundaries ARE the container's index entries, and containers disagree about what an entry's timestamp means: a mov/mp4 sample table holds decode times, a Matroska Cue holds a presentation time. Since #358 the VOD cutter gate compared decode times against both. Correct for mov/mp4, wrong for every Matroska whose video carries composition offsets, which is every MKV with B-frames.

On those sources no IRAP ever reaches its own boundary, because its decode time sits a composition offset below it. The gate never opens on the planned keyframe, so audio, which is routed by boundary and not gated, opens the segment instead and the IRAP stays in the segment before. Every segment then begins mid-GOP, roughly one IRAP below its own first random-access point, which is what #412 seg-N opens 0.751s below its first random-access point reported on every single segment of the field report.

Nothing in such a segment can start a decode run. Playback survives while AVPlayer decodes THROUGH the boundaries and stops with CoreMediaErrorDomain -19602 the first time it has to decode FROM one, which is why the reporter measured it at specific places in the film rather than after a fixed time, and why the automatic item reload died on the same segment again.

The gate now compares a packet on the plan's own axis (PlanBoundaryAxis, read from the container the demuxer actually opened, never from the URL or host metadata). mov/mp4 sessions are unchanged byte for byte.

One HEVC stream muxed into both containers by stream copy, so the packets and timestamps are identical and the index stamping is the only difference:

	first video 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 is affected identically, so this is a property of the container rather than of HEVC.

2. The bridge's published origin accounts for the encoder's priming

baseMediaDecodeTime is unsigned int(64), so a negative published timestamp is unrepresentable rather than merely unusual.

The audio bridge stamps the FRAME it hands the encoder, and an encoder that declares initial_padding stamps its first PACKET a padding below that frame, so a consumer that discards the priming lands back on the source position: 256 samples on the AC-3 family, which surround-compat mode reaches for above two channels, and none on FLAC. Nothing discards it here, because the muxer writes no edit list on purpose. At source position 0 the published timeline therefore started negative: -256 went out as 2^64 - 256 and the whole first audio fragment was placed 584 thousand years out, losing its ~190 ms of audio at the start of every bridged multichannel session.

Visible in the reporter's own captures, where the TrueHD track (bridged, EAC3 encoder) carries tfdt 0xFFFFFFFFFFFFFF00 while the same file's DD+5.1 track (stream copy, no bridge) starts cleanly at 0. Reproduced here on 5.1 PCM in Matroska, down to the same value.

The counter now carries the padding, which costs the content 5.3 ms, two orders below the lip-sync threshold and what an unsignalled priming is worth. The FLAC path is unchanged, measured.

3. The boundary tolerance stops paying for a skew its axis does not have

The AE#408 tolerance, which decides when a segment opened so far past its boundary that a second seek is worth it, carried the stream's reorder depth. That term pays for the axis mismatch above, not for anything the stream does, and a Matroska Cue has no such skew. On that axis the tolerance is now the floor, which sharpens the decision on the container AE#408 was reported against; mov/mp4 keeps the term.

The gate's own comparison is deliberately left lenient, and the reasoning is now written down instead of assumed. It answers a different question than the cutter does, being wrong in the strict direction costs the whole restart, and the reported AE#169 geometry has the boundary falling BETWEEN the anchor keyframe's two timestamps, matching neither axis.

Verification

Each fix has a witness that fails without it: PlanBoundaryAxisTests fails on the Matroska arm alone, BridgedAudioOriginTests fails with exactly the reported 18446744073709551360, and the tolerance arms are pinned in Issue408BoundaryRandomAccessTests. Full suite green over both runners, exit 0. Fixtures come from Scripts/fetch-fixtures.sh; the tests skip when they are absent.

🤖 Generated with Claude Code

https://claude.ai/code/session_015PM3xUJB6ZQyqnmGK1fp6F