6.20.1 - A cut gate that reads the plan's own axis

Drop-in from 6.20.0. One axis, one line, and the root cause behind the #358 stalls 6.20.0 could only mitigate.

A cut gate that reads the plan's own axis

A keyframe-aligned segment plan is built from the container index's sync-sample timestamps. For mov/mp4 those are DECODE timestamps: the mov demuxer builds its index from current_dts. The cut gate compared a packet's PRESENTATION timestamp against them.

The two differ by the sample's composition offset. On an ordinary encode that is two frames, and nothing shows, which is how this survived since #92 shipped the keyframe-gated cut in 4.8.0. On a remux carrying an edit list it is seconds. The reported file opens with

first video pkt: dts=0 pts=300000        (time base 1/100000, so exactly 3 s)

so every keyframe reached boundaries up to 3 s beyond its own, and the cutter consumed them. Those plan indices then never opened a segment while the playlist kept offering them, which is the stall: the request rides out the slow threshold and the session freezes with the engine still reporting playing.

Reproduced without the reporter's file

Give a normal encode the same shape, which the setts bitstream filter can do directly:

ffmpeg -f lavfi -i testsrc=size=640x360:rate=25:duration=90 -c:v libx264 -preset medium -bf 3 \
  -g 105 -keyint_min 105 -sc_threshold 0 -pix_fmt yuv420p -an base.mp4
ffmpeg -i base.mp4 -c copy -bsf:v "setts=pts=PTS+64000:dts=DTS" -muxdelay 0 -muxpreload 0 offset.mp4

• 5 s offset, IRAPs every 4.2 s: segment 0 was never opened at all, so the session never started (final t=-5.08s, seg0 slow-served forever).
• 3 s offset, wider boundaries: no missing index, but a constant drift=-2.480s on every ledger line, a whole keyframe interval of plan-versus-content disagreement that nothing reported.

Both now read drift=0.000 throughout and play through.

What did not change

Keyframe gating. The IRAP is still the segment's first sample and its open-GOP RASL pictures still follow it in decode order, which is what #92 exists for. segverify reports 6/6 segments independently decodable on a B-frame encode, the case #92 was filed for, and 5/5 on the offset fixture. Sources that carry no DTS fall back to the presentation timestamp, so their behaviour is untouched.

Suite is 1737 tests in 254 suites; aetherctl play verified on both offset fixtures, a B-frame mp4, the #358 long-GOP TS, a53-captions, sdr-h264 and hdr10-hevc.

Reported by @DrHurt through AetherPlayer#2 and tracked in #358, whose third round of logs carried the line that identified this.