mirror of
https://github.com/zoriya/v10.git
synced 2026-08-09 23:58:06 +00:00
Christian PillsburyandClaude Opus 4.8
c3e137cf39
Make a complete VOD reach native `ended` (and loop) reliably even when audio and video tracks end a few ms apart, via two narrow changes in the behaviors that already own end-of-playback: 1. `end-of-stream` reactor — add `LAST_SEGMENT_REACHED_SLACK` (0.5s) to the "playhead reached the last segment" gate. A tiny final segment (e.g. Apple's ~44ms last segment) starts at the buffered end and Chrome freezes the playhead ~50-70ms short of it, so a strict `currentTime >= lastSegStart` never opens -> `endOfStream()` never fires -> MediaSource stays `'open'` -> frozen. The slack fires EOS just before the freeze. 2. `recover-end-stall` (new DOM behavior) — on `waiting`, if the MediaSource is `'ended'`, duration is finite, and the playhead is within `endStallNudgeWindow` (0.2s, config) of the reachable buffered end, nudge `currentTime = duration` to force native `ended`. Event-driven, no poll (`waiting` fires at ~0ms). Inert for live and clean-ending streams. Composed in both engines. ADR: internal/decisions/end-of-stream-av-skew-recovery.md 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