PLAN: the Ham Share player and the Transcode device setting; e2e-player.mjs

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

PLAN.md

@@ -810,6 +810,51 @@ something long in one, switch away and back, refresh — it's all still there.
   - Tested (`TestSeekRestartsTheEncode`): a 64 s 1080p clip, a request for segment 12 right
     after the start runs from 48 s, the gap is filled, all 16 segments joined behind the one
     init decode with no hole.
+- **The player is Ham Share's; a Transcode device setting** — **2026-10-23** (v0.1.0-226,
+  `internal/media/{encode,play}.go`, `internal/api/play.go`, `Player.tsx`, `vr.ts`,
+  `Settings.tsx`). Asked for as "redo the HamLab one with the one you sent … a 'Transcode
+  Device' setting … the A380 on Grid selected … other options being the other transcode
+  devices like the iGPUs on the various CPUs that have HamLab installed". **Replaces** the
+  previous two entries' design: no codec/size picker, no single-quality re-encode, no
+  repackaging; the old streamer (`hls.go`) is gone.
+  - **YouTube's way:** Auto (hls.js reads the connection), any quality by hand, or Original
+    (the file as it is, `/api/files/read`, falling back to Auto when the browser can't). A
+    ladder by size (`Ladder`): flat 2160p/1440p/1080p/720p/480p by the short side, plus the
+    file's own size on top when it sits between steps (a 2292×960 capture gets 960p); 360
+    files by width, named as YouTube does (2160s 3840 … 720s). 720 and down at ≤30 fps.
+    H.264 High + AAC only.
+  - **Pieces made when asked for**, 3 s MPEG-TS, every quality's playlist written whole up
+    front. One ffmpeg per play: it starts at the piece asked, runs ahead, and is paused
+    (SIGSTOP; a root run through `run-ffmpeg`, which now reads `stop`/`cont` on stdin) 10
+    pieces ahead; a piece more than 3 past what's made, or at another quality, starts a new
+    run there. Keyframes only on the 3 s marks and every run's times offset alike
+    (`-output_ts_offset start+10`), so pieces from any run and quality join (`TestPieces`
+    checks it; `SRC=… DEVICE=… go test ./internal/media -run Pieces` on a machine with a GPU).
+    At most 3 runs a machine, the one asked of least lately ended for a fourth; 2 GiB of
+    pieces a play; forgotten after 30 min.
+  - **hls.js is patched** (`PatientAbr`): the wait for a piece being made isn't counted
+    against the connection, and a piece isn't abandoned before its first byte. Without it
+    Auto dropped to the bottom after every seek.
+  - **Transcode device** (Settings, hub-side, `store.Transcode`): every machine's devices
+    asked live (`GET /api/files/play-devices` on each), unusable ones greyed with the reason
+    (hamtv's UHD 600: the render permission; mac and gate: no ffmpeg). Set to **grid's Arc
+    A380**. "The machine the file is on" is the other choice. `POST /api/play` on the hub
+    opens the play where the setting says; **a machine transcoding another's file reads it
+    through the hub** at `/api/play-src/<token>` — a random token good for that one file, 12
+    h from its last use, ranges passed through to the file's machine (ffmpeg reconnects).
+    If that machine fails, the file's own makes it and the player says so.
+  - Recipes per device: same-card decode first, then CPU decode + upload, then libx264 as
+    the fallback whatever was asked. A card without `vainfo` (core) is tried anyway: core's
+    UHD encodes. **Rotation:** the card path turns a phone's picture itself
+    (`transpose_vaapi`, `-noautorotate`; ffmpeg's autorotate never applied to VAAPI frames,
+    so iPhone clips came out sideways). **HLG** is shown as it is (tonemap_vaapi refuses it);
+    HDR10 is tone-mapped on the card, else zscale/hable before the upload.
+  - 360 files: the look-around view, zoom 8°–300° (ordinary lens into stereographic, the
+    "little planet"), drag/pinch/wheel, phone motion. Full screen is the element's, or the
+    whole window on an iPhone.
+  - Measured (`web/scripts/e2e-player.mjs`, Chromium): an iPhone HLG clip on `core` made on
+    grid's A380 — 3.2 s to play, a seek 1.0 s, a quality change 1.5 s; the 8K 360 Disney day on
+    grid — 3.1 s, 2160s on Auto, a seek 4.9 s (10 s source keyframes).
 - **Files edge sweep** — **2026-10-11** (v0.1.0-214), asked for as "a full bug sweep of
   the Files section, every example and edge case". Every handler and both UI files read
   through with odd inputs in mind, then a battery of ~60 requests against the live hub