* fix(playback): claim Safari DV/HDR10 decode evidence and preserve dvvC
Follow-up to #613 for #609: Safari 26 reports dynamic-range: standard even
on an XDR display, and answers canPlayType "probably" only for dvh1/hvc1
sample entries, never dvhe/hev1. The web probe gated every structured HDR
claim on that media query and probed only dvhe, so the planner still saw
empty hdr_details and terminated with hdr_transcode_unsupported.
- Run the Dolby Vision and HDR10 shape probes unconditionally; the
dynamic-range query survives only as the best-effort hdr output boolean.
- Probe dvh1+dvhe per DV profile and hvc1+hev1 for the exact HDR10
Media Capabilities shape; either definitive answer earns the claim.
- Tag preserved-DV remuxes dvh1 with -strict unofficial: FFmpeg omits the
dvvC configuration record under either tag without it, so the previous
dvhe output carried no DV signaling at all.
- Scale the screen-derived max_resolution by devicePixelRatio so 2x
panels stop advertising 1080p.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(playback): align DV/HDR10 claims with the sample entries the remux emits
Review follow-ups on #617 (Codex P1s):
- Probe only dvh1: a browser answering "probably" solely for dvhe has
given no evidence for the dvh1-tagged file the preserve remux delivers,
so that answer no longer earns a Dolby Vision claim; such browsers keep
the validated HDR10 fallback.
- Label the explicit v3 HDR10 strip output hvc1 so the file matches the
hvc1 evidence the web probe accepts; legacy/auto strips keep hev1.
- Cover preserve tagging for profiles 5 and 8, and exercise the
mode-to-argument mapping through StartRemuxWithDVMode instead of
passing the tag flag directly.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(playback): name the subtitle when burn-in alone forces a refused transcode
Selecting a PGS/VOBSUB track on a client without a bitmap renderer forces
a burn-in transcode. When that transcode cannot run, the terminal blamed
the HDR pipeline (hdr_transcode_unsupported) or the 4K policy
(no_alternate_version) — problems that were not blocking playback, since
deselecting the subtitle restores the previous route.
- When the burn requirement is the sole trigger of the adaptation, the
HDR and 4K-policy terminals emit subtitle_conversion_unsupported with
a message naming the burn requirement and the actual blocker. A range
the client genuinely cannot take keeps the HDR terminal.
- describePlanTerminal passes the server's subtitle message through
instead of flattening every subtitle_* reason to one generic sentence.
- The web player toasts the refusal when it rolls the subtitle selection
back; previously the only surface was the quality menu, which a user
who just picked a subtitle has no reason to open.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(playback): require decode evidence for the exact hvc1 entry and gate the disabled-transcode subtitle terminal
Review follow-ups on #617:
- The HDR10 probe accepts only hvc1.2.4.L153.B0: the explicit v3 strip
remux labels its output hvc1, so an hev1-only decodingInfo answer is
evidence for bytes Silo never sends and earns no claim (Codex P1).
- The disabled-transcode branch blames the subtitle only when the burn
requirement was the sole adaptation trigger; other causes keep
transcoding_disabled. In practice a bitmap selection without transcode
terminals in the subtitle policy before this branch, but the guard
keeps the sole-cause invariant if that ordering ever changes
(CodeRabbit / Codex P2).
- Protocol doc scopes the hvc1 labeling to the explicit v3 strip path;
legacy/auto strips keep hev1 (CodeRabbit).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
