mirror of
https://github.com/zoriya/v10.git
synced 2026-08-16 02:45:09 +00:00
Christian PillsburyandClaude Opus 4.8
0cb33bb532
Rework live anchoring around a single shared anchor established only from
authoritative buffer ground truth, dropping the unreliable manifest estimate:
- anchorLiveTracks establishes the anchor once per source from the first
actually-buffered A/V track (the buffer actor's `initTrackId`, not the
selection), stamps it onto every track via `positionAllTracksToAnchor`
(resolved tracks shift; not-yet-resolved shells get `startDate` for the
parser's `placeOnAnchor`), and publishes it as `liveAnchor`.
- seekToLiveEdge gates its live-edge seek on `liveAnchor`: with no estimate the
pre-anchor window is the raw one, and seeking there would strand the playhead
when the pin later shifts the window. Gating holds the seek until the timeline
is anchored, so it targets the final native-PTS window. (Smoke-tested on Mux
LL-HLS: single seek to the live edge after the pin, clean startup.)
- The resolveBufferedAnchor seam becomes `(deps) -> { trackId, segmentId,
actualStart }`, reading the buffer actor directly (video-first).
An intermittent ~2 s audio model-`startDate` offset (buffers stay aligned, so
playback is synced) remains, tracked as a separate startup race.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Decisions
ADR-style records of single tactical decisions.
What Belongs Here
A decision doc captures one specific choice: what was decided, why, and what was ruled out. Keep them short and focused — usually one page.
Write one when:
- You picked one approach over another and want the reasoning on record.
- A decision depends on or supersedes an earlier one (link across docs).
- You want future contributors to understand why the code is the way it is.
Decisions vs Design Docs
Use a design doc (internal/design/) when you're specifying architecture, a feature, or a subsystem — forward-looking, often longer, status ranges from draft → decided → implemented → superseded.
Use a decision doc here when you're recording a single trade-off within that work — short, always status: decided.
A design doc often spawns several decision docs as implementation choices get made.
Format
---
status: decided
date: 2026-01-27
---
# Title
## Decision
What you decided. Be direct.
## Context
Why this came up. What problem triggered the decision. Link related decisions.
## Alternatives Considered
- **Option A** — Why not chosen
- **Option B** — Why not chosen
## Rationale
Why this choice wins. Keep concise.
File Naming
Lowercase with hyphens, name after the subject of the decision:
captions.md
gestures-as-components.md
provider-attach.md
See Also
- Design Docs — Architecture specs and feature designs
- RFCs — Proposals needing buy-in
- Plans — Implementation notes
- CLAUDE.md — How these relate