From d4b21954bcc7ee60f09e4468887cd7b392e7d902 Mon Sep 17 00:00:00 2001 From: Christian Pillsbury Date: Thu, 25 Jun 2026 14:20:47 -0700 Subject: [PATCH] docs(spf): note EVENT detection is now consumer-reachable The DVR-vs-live distinction open question's PLAYLIST-TYPE:EVENT option is available today: playlistType is exposed via getMediaPlaylistMetadata on @videojs/spf/hls and used by the sandbox. Co-Authored-By: Claude Opus 4.8 (1M context) --- internal/design/spf/features/dvr-event-stream-support.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/internal/design/spf/features/dvr-event-stream-support.md b/internal/design/spf/features/dvr-event-stream-support.md index 570eb772..1a272ed7 100644 --- a/internal/design/spf/features/dvr-event-stream-support.md +++ b/internal/design/spf/features/dvr-event-stream-support.md @@ -172,7 +172,11 @@ Things this feature probably forces decisions on, not just additions: inference. (a) is simplest; (b) only covers spec-flagged event streams; (c) is the most adaptive but adds complexity. Likely combination: (b) when the tag is present; otherwise (a) until (c) - matures. + matures. Update: the parser already extracts `playlistType` + (`'VOD' | 'EVENT'`) into the media-playlist metadata, now consumer-reachable + via `getMediaPlaylistMetadata` on `@videojs/spf/hls` — so (b) is available + today (the `spf-segment-loading` sandbox uses it to classify DVR/EVENT vs + sliding live, replacing an earlier window-size heuristic). - **Seekable-range start derivation under server retention.** When the server keeps only the last N hours of segments and the playlist's first segment slides forward over time, the