Cross a clip join per track, not on the video's frame

The first cut placed every track with the cursor the video had moved. At
an overlap join the previous clip's audio is still arriving after video
has crossed, and those tail frames sit inside both clips' mark ranges —
so they took the new clip's offset, jumped forward by the overlap, and
collided with the new clip's own audio, which the muxer's monotonic nudge
then flattened. A remux confirmed it: the timeline length was already
correct and the original symptom was still there, 169 audio packets on
the tick floor.

A track's PTS only runs forward inside a clip, so its own backward step
to the next clip's IN is its crossing. That is per track, so the cursor
is too.
This commit is contained in:
Matthew Jackson
2026-08-05 15:46:40 -07:00
parent ce246a1c87
commit 3090314717
3 changed files with 139 additions and 78 deletions
+1 -1
View File
@@ -1411,7 +1411,7 @@ impl<W: Write + Seek> MkvMuxer<W> {
// outside every clip's IN/OUT marks, which only a seam-plan-driven
// title can report. Dropping it is the point: emitting it is what put
// duplicate content on the timeline at a join.
let Some(pts_ns) = self.continuity.map(pts_ns, drives_epoch) else {
let Some(pts_ns) = self.continuity.map(pts_ns, drives_epoch, track_idx) else {
return Ok(());
};
let raw_ticks = pts_ns / TIMESTAMP_SCALE_NS;