Sample two short windows before re-encoding a cached video and skip the full encode when HEVC will not save 15 percent

CLAUDE.md

@@ -44,11 +44,16 @@ JSON shapes mirror the Tauri Rust bridge exactly — don't change one side alone
   different bytes. A replaced gen is kept 30 min so in-flight Range playback survives.
 - **Compression lane** (rev `OPT_REV` = 2): niced x265 8-bit `-preset medium -crf 28`,
   `hvc1` tag, anime-style tuning (`X265_TUNING`), `-fpsmax 30`, audio copied — kept only
-  if ≥15% smaller, and the copy's `vcodec` becomes `hevc`. Benchmarked 2026-09-13 (VMAF,
-  codec-test page in Windows Docs): x264 can NOT beat YouTube's own H.264 (needs more
-  bitrate at equal quality); x265 cuts live worship video ~35–44% at ~2× realtime on the
-  homelab's 2 threads; lyric videos (~47 kbps video, mostly audio) keep the original.
-  Bumping `OPT_REV` re-queues every cached copy once at boot.
+  if ≥15% smaller, and the copy's `vcodec` becomes `hevc`. **Sample-first**: videos ≥60 s
+  get two 10-s windows encoded first and compared with the source's own packet bytes
+  over the same timestamps; the full encode only runs if the prediction clears the 15%
+  bar (a skip costs ~20 s of video; a full encode ~2× realtime on the homelab).
+  **Why:** re-encoding YouTube's already-compressed H.264 usually needs MORE bits for
+  LOWER quality (generation loss) — on prod 0 of 5 videos shrank at CRF 28, one grew 25%
+  (VMAF 93.6 at 126% of source; capping to 60–70% drops VMAF to ~84–87). Only videos
+  where YouTube over-spent bits win (a live worship video: −34%). AnimeOut-style sizes
+  come from pristine Blu-ray sources, which YouTube never gives us. Bumping `OPT_REV`
+  re-queues every cached copy once at boot.
 - **HEVC gating**: an HEVC copy is served only to clients that send `?hevc=1` on
   `/api/streams` and `/api/download` (app.js `hevcCapable()` = canPlayType hvc1, minus a
   per-device `ytpNoHevc` flag set when an HEVC copy fails to play). Everyone else gets