From 677775266217b08044fe734be78f0e1bc874d708 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Thu, 17 Sep 2026 11:23:36 +0200 Subject: fix(node): a seek left the audio a GOP behind the picture MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -ss before -i cannot trim copied video, which must begin on a keyframe, but accurate_seek did trim the re-encoded audio to the exact request. Every seek on a copied stream therefore opened with a GOP-wide hole in the audio and ran a GOP out of sync afterwards — 9.979s on a real film with a 10s keyframe interval. Accurate seeking is now off wherever video is copied, and stays on where it is re-encoded, which is the only path that could already begin where it was asked to. Every timestamp was correct throughout, which is why nothing caught it; the tests assert on decoded audio and on frames compared against the source. Co-Authored-By: Claude Opus 5 --- docs/MESHBAY_DESIGN.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'docs/MESHBAY_DESIGN.md') diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index e7d4a76..ef65995 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -2031,6 +2031,21 @@ MSE string) fed to a source buffer, with the node holding one slot per viewer. - **Seeking restarts the source with an index seek before the input**, clamped away from the end and echoed back; the client supplies the timestamp offset, because copying timestamps does not preserve position. +- **A seek trims what it can, and what it can differs per stream — which is a + desync, not an inconvenience.** Accurate seeking cannot trim copied video, which + must begin on a keyframe, but it does trim re-encoded audio to the exact request. + The output then carries video from the keyframe and audio from the request, a + whole GOP apart, with a hole between them. So **accurate seeking is off wherever + video is copied and on wherever it is re-encoded**, which is the only place the + two can agree on where to begin. + + > **Every timestamp was correct while this was happening.** First PTS per stream, + > durations, spans, and the browser's own audio/video delta through MediaSource + > all agreed, because both streams genuinely sat where the container said. Only + > the *content* at a given instant was displaced. A property that every + > timestamp-shaped check confirms is not thereby true: this one needed the output + > decoded and compared against the source, frame against frame and envelope + > against envelope. - **The viewer picks the audio track, and picking one is a seek.** One ffmpeg carries one audio track, so there is nothing to switch inside a running stream: the node is asked again at the current position and the source buffer is reset -- cgit v1.2.3