mirror of https://github.com/zoriya/v10.git synced 2026-08-16 02:45:09 +00:00

Files

T

Christian PillsburyandClaude Opus 4.8 0cb33bb532 refactor(spf): establish the live anchor from buffer truth and gate the seek on it

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>

2026-06-25 10:00:46 -07:00

README.md

Design Docs

Decisions you own — documented for posterity.

What Belongs Here

Design Docs are decisions you own. Write one when:

Making architectural decisions in your area
Choosing between implementation approaches
Introducing design patterns others will follow
Documenting internal APIs or component specs

When to Use RFC Instead

Use an RFC (rfc/) when:

Changes public API surface
Affects product direction
Affects user-facing developer experience
Significant changes to core architecture
Hard to reverse once shipped

Rule of thumb: If you need someone else's approval, it's an RFC. If you're documenting your own decision, it's a Design Doc.

Format

---
status: decided
date: 2025-01-27
---

# Title

## Decision

What you decided. Be direct.

## Context

Why this came up. What problem triggered the decision.

## Alternatives Considered

- **Option A** — Why not chosen
- **Option B** — Why not chosen

## Rationale

Why this choice wins. Keep concise.

Status Values

Status	Meaning
`draft`	Thinking through it, not final
`decided`	Decision made, documented
`implemented`	Built and shipped — kept for rationale
`superseded`	Replaced by another design doc

File Naming

Use lowercase with hyphens:

queue-design.md
hook-naming.md
skin-theming.md