Deployed 811e0a1 with MkDocs version: 1.6.1

dev/creating-a-service/index.html

@@ -2890,13 +2890,16 @@ audio, add hand-built subtitles or an <code>Attachment</code> (e.g. cover art).
 filter for resolution/bitrate. See <code>fetch_dash_manifest</code> in the EXAMPLE service
 for a thorough demonstration.</p>
 <div class="admonition note">
-<p class="admonition-title">Flip HDR10 → HDR10+ by hand when you know the platform embeds it</p>
-<p>HDR10+ is a <strong>bitstream (SEI)</strong> feature. The HLS parser intentionally does
-not sniff it from the bitstream, so a manifest that embeds HDR10+ SEI but labels
-the variant plain HDR10 will parse as HDR10. The label is the only signal
-the parser has, and it is wrong. Only the service author knows the platform
-embeds HDR10+, so it is on you to correct <code>video.range</code> to HDR10+ here for
-those services.</p>
+<p class="admonition-title">HDR10+ in tracks labelled HDR10</p>
+<p>HDR10+ is a <strong>bitstream (SEI)</strong> feature, and many manifests label an HDR10+
+variant as plain HDR10. Before unshackle lists or selects tracks, the
+<a href="../../reference/configuration/download/#hdr10plus_probe"><code>hdr10plus_probe</code></a>
+reads the first fragment of each HEVC HDR10 track and changes <code>video.range</code> to
+HDR10+ when the fragment carries HDR10+ metadata. Set <code>video.range</code> yourself
+only when the probe cannot read the fragment, for example an ISM track whose
+SEI is encrypted, or when the platform gives a reliable signal of its own.
+If the playback API has no HDR10+ value, request HDR10 for an HDR10+ request
+and let the probe relabel the tracks.</p>
 </div>
 <div class="admonition warning">
 <p class="admonition-title"><code>get_tracks</code> is your only chance to capture license inputs</p>