[kixelated]

Problem

https://vid.moq.dev/bbb.mp4 has packets that repeat their predecessor's timestamp: two video frames (182.856 s and 596.440 s) and three AAC frames (182.880 s, 182.927 s, and 596.474 s). ffmpeg's demuxer flags each repeat discard, but -c copy still publishes it, nudged one 90 kHz tick later in MPEG-TS. An exporter on a millisecond clock (FLV, MKV) then sees two frames on one tick. Both video repeats are coded reference P-frames, so dropping them corrupts decoding until the next keyframe. bbb.py filtered discard packets out of its own checks, so it never saw them, and the SD rendition's encode dropped the two video frames.

Approach

• bbb.py retime (just pub retime-bbb) remuxes the source with -c copy, moving only the repeats. The first frame of a pair takes the frame slot missing just before it, if there is one; every audio repeat follows such a gap. Otherwise the second frame moves halfway to the next packet or to its stream's end. The remux fails unless exactly those packets moved, every stream keeps its duration, and timestamps strictly increase. A source with no repeats is left untouched. Payloads are byte-identical; only packet interleaving changes.
• bbb.py check, which runs nightly as pub check-bbb, now requires both renditions to keep every packet, with no discard flags and strictly increasing timestamps on every stream. It fails on the previously hosted files.
• The SD rendition is re-encoded from the retimed source. It now carries all 14315 frames.

The hosted files are replaced, and the old ones are kept as the way back:

Object	Old sha256	New sha256	Old copy
bbb.mp4	cc1d8a9536a7a0f2520a8985ec14e535f265ffec148df690c3b2fa3152176f39	6ab011e67d002aa95e4e8792f6847777cd0ffa29254a8d4aa61208ac253a77f2	archive/bbb-cc1d8a95.mp4
bbb-sd.mp4	42cfa14cba70758078385a46f7fdde66404d28eab02df91b83b5bd16186c0c41	0b93401e23a5c5e5487b59804e2b7045933efa4c10796a2d9d5e5bef0a4b032e	archive/bbb-sd-42cfa14c.mp4

To roll back, copy each archived object back over its name: curl -fsSL https://vid.moq.dev/archive/bbb-cc1d8a95.mp4 -o media/bbb.mp4 && just pub upload bbb.mp4, and the same for the SD file.

just pub check-bbb passes on a fresh download of the new files.

Impact

• No API or wire change. vid.moq.dev/bbb.mp4 and bbb-sd.mp4 changed content. A host that cached the old files (just download skips an existing file) keeps them until it deletes them.

Alternatives

• Drop the repeats: they are reference frames, so the frames after each would decode corrupted until the next keyframe.
• Move every repeat halfway to the next packet: for the audio, that overlaps 512 samples with the next frame and leaves the gap before it empty.

Follow-ups

None. The exporter side is moq-dev/moq#8715, which presents a sub-tick tie one tick later rather than failing.

Models

Size: S
Implementer: Claude Code, claude-opus-5-5, medium effort (iterate, S)

(Written by Claude Opus 5.5 with medium)

Review

Rewritten by quest review after each round.

• Reviewer: Codex, gpt-6.1-sol, medium effort
• Session: 01a1d835-ead4-7e11-9262-e9eef572e4e6, round 2
• Head: 9dcf9e0
• Base: origin/main at 93cd63e
• Score: 9/10, The cleanup fix removes the temporary remux on command or validation failure before re-raising, with no actionable defects found in the incremental diff, though runtime behavior was not tested as instructed.
• Findings: none

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 10 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 4 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 0ee1b29f-ce6f-4500-be52-6232ec2565dc

Commits

Reviewing files that changed from the base of the PR and between dcf9029 and 9dcf9e0.

Files selected for processing: 2

• demo/pub/bbb.py
• demo/pub/justfile

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[pullfrog]

ℹ️ No critical issues — one minor suggestion inline.

Reviewed changes

Reviewed the initial commit, which adds a retime step for bbb.mp4 and makes check require strictly increasing, non-discarded packets on every stream.

• retime action — moves only the packets that repeat a timestamp, remuxes them with a per-stream setts bitstream filter, then checks that only the planned packets moved, that stream durations are unchanged, and that timestamps strictly increase before replacing the source.
• Stricter check — video() no longer filters out discard-flagged packets, and the new strict() runs on every stream of both renditions, audio included.
• just pub retime-bbb — a new recipe that wraps the retime step. The check-bbb comment was updated to match.

The check after the remux is a good safety net. If ffmpeg's setts counter N does not line up with the packet indices, or if -copyts or the time base shifts a timestamp, the run fails with an error instead of quietly writing a bad file. Triple repeats, or repeats with no room to move, also fail through the asserts.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using claude-opus-5-5 ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes

Reviewed the delta since the prior Pullfrog review (2f5e3dc → 9dcf9e0).

• Temp file cleanup in retime — the ffmpeg remux and the post-remux checks now run inside try/except BaseException, which unlinks media/bbb.tmp.mp4 and re-raises. A rejected remux can no longer be picked up by just pub sync. This resolves my earlier inline thread.

  ^{｜ View workflow run ｜ Using claude-sonnet-5-5 ｜ 𝕏}