Added notes about Millicast account IDs in the source domains

[turbidwater]

Updating docs for the work on adding Millicast account IDs to source domains listed in the license.

[devin-ai-integration]

Review — docs for OPTIP-374

Content matches the corresponding Web SDK change, lands on the current (v11) page with the v4–v10 versioned copies correctly untouched, prettier is clean and pr-lint is green. Four wording points:

1. The implicit THEO domains aren't THEOlive-specific. The SDK allows theo.live / dolby.com (and subdomains) for every non-Millicast source, not only THEOlive-resolved endpoints, so the current framing under a THEOlive sentence understates it. Suggest stating the implicit allowance as a general source-domain rule, then adding the THEOlive consequence.

2. No platform/version scope. This FAQ is cross-platform and the page-domains section explicitly annotates applicability ("available only on Web SDK, React Native SDK and Flutter SDK"). The millicast:// support is Web-only for now (Android/iOS are separate pending tickets), so the new paragraphs should say which SDKs/version support it — otherwise Android/iOS customers will configure entries that do nothing on those platforms.

3. Worth calling out that every source in a source description is checked individually. A Millicast source with an HLS/DVR fallback on a customer domain needs both the millicast:// account and that domain listed, otherwise the whole source description fails. That's the most likely support ticket from this change.

4. Matching is exact/case-sensitive on <streamAccountId> — worth one sentence, since account IDs are mixed-case (e.g. k9Mwad).

Also note (no doc change wanted): the SDK additionally allows an internal staging domain that is intentionally not documented here — fine, just flagging so nobody "completes" the list later.

[theoplayer-bot]

Documentation preview
🚀 View preview at https://docs-preview.optiview.dolby.com/pr-830/
Deployed from commit a224a01 at 2026-08-26 22:37 UTC.

[turbidwater]

1. It should be fine being limited in the docs to this scope.
2. Android and iOS versions of the feature should land at the same time as the Web.
3. Agreed. Done.
4. Agreed. Done.

[devin-ai-integration]

Re-review of a224a01e

Points 3 (per-source checking) and 4 (exact/case-sensitive matching, now with a realistic mixed-case example) are addressed well. CI is fully green and prettier is clean. Two of the earlier points are still open, plus one new observation:

1. Implicit THEO domains are still framed as THEOlive-only (open). In the SDK the implicit theo.live / dolby.com allowance applies to every non-Millicast source, not just THEOlive-resolved endpoints, so a customer serving a plain HLS URL from a dolby.com subdomain is also implicitly allowed. Suggest splitting it, e.g.:

   Sources delivered from THEO's own domains (theo.live, dolby.com, and their subdomains) are implicitly allowed, even when they are not listed in the license.

   THEOlive-resolved endpoints are subject to the same source-domain check as other sources. THEO-hosted endpoints are therefore always allowed, while endpoints on other domains, such as customer-configured delivery domains, must be listed in the license's source domains.

2. Still no platform/SDK scope for millicast:// (open). The page-domains section states its applicability ("available only on Web SDK, React Native SDK and Flutter SDK"), and this FAQ is read by Android/iOS customers too. millicast:// entries are Web-only for now, so without a note like "(currently enforced by the Web SDK only)" those customers will configure entries that silently do nothing on their platform. The license itself is cross-platform, so this is the one gap that can actively mislead.

3. New, minor: this revision also rewords the whole page (title-case → sentence case, "THEOplayer SDK/license" → "player SDK/license"). No objection to the wording itself, but it's unrelated to OPTIP-374 and it makes the v11 page diverge in style from the v4–v10 versioned copies, which still use the old capitalization and "THEOplayer". Fine if the branding sweep is intentional; otherwise it might be cleaner as a separate change.

Also mentioned separately (not a docs change): the PR description links to the internal SDK repo — worth replacing with a generic reference, since this repository is public.