feat(mediaplayer): HLS / Low-Latency HLS playback (Windows) (#837)

## Summary
Adds an HLS / Low-Latency HLS source to the media player, layered on top
of the existing OS-codec path.

`.m3u8` URLs are handled by a new `protocol/basis_hls.c`, which is
**not** a demuxer — it parses the M3U8, selects a single rendition,
starts near the live edge, and stitches the segments (and, for LL-HLS,
the `EXT-X-PART` partial segments) into one continuous byte stream that
the existing MPEG-TS / fragmented-MP4 demuxers consume. A background
reader paces delivery to the stream's measured average bitrate so the
present path is fed at real time rather than flooded, with enough burst
headroom to deliver segment-start keyframes promptly. When the origin
advertises `EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD` with parts, it uses
blocking `_HLS_msn`/`_HLS_part` playlist reloads and rides parts to
target roughly `PART-HOLD-BACK` latency (~5 s); against a plain HLS
origin you get its segment-bound latency instead.

**Scope:** Windows (WinHTTP fetch), clear streams, single rendition.
Android/Quest support is planned.

**Additive only.** The existing RTSP / RTMP / MPEG-TS / fMP4 / HTTP
implementations have zero source edits — `basis_media_core.c` only gains
a `.m3u8` branch ahead of the plain byte-source path, so every other URL
(`rtsp` / `rtmp` / `.ts` / `.mp4`) takes the identical existing route.
The Windows x86_64 DLL is rebuilt to include the new source; RTSP and
MPEG-TS are behaviourally unchanged, only recompiled. No C# changes.

- `protocol/basis_hls.c` / `.h` — new HLS source (M3U8 parse,
segment/part scheduler, paced read-ahead buffer)
- `basis_media_core.c` — route `.m3u8` to the HLS source, feeding
`basis_ts_run` / `basis_mp4_run` unchanged
- `CMakeLists.txt` — add `basis_hls.c` to the portable core
- `README.md` — document HLS support and the Windows / clear /
single-rendition scope

## Required checks
All boxes below must be ticked before this PR can merge. If a check is
genuinely N/A, tick it anyway and explain under **Notes**.

<!-- required-checks-start -->
<!-- Tick the boxes in place — do not edit the line text. The
pr-checklist workflow parses this block; per-PR context goes under
Notes. -->
- [x] **Tested** — I built and ran this locally. The change works in the
editor and (where relevant) in a built player.
- [x] **Transform access is combined and limited** — In hot paths,
transform reads/writes go through `TransformAccessArray` or are
otherwise batched. I have not added per-frame `transform.position` /
`transform.rotation` / `transform.localPosition` calls inside loops.
Whenever I need both position and rotation, I use the combined APIs —
`SetPositionAndRotation` / `SetLocalPositionAndRotation` for writes,
`GetPositionAndRotation` / `GetLocalPositionAndRotation` for reads —
instead of two separate property accesses; the combined call does one
local-to-world matrix traversal instead of two.
- [x] **Addressables used for asset/memory loading** — Any new asset
loads go through Addressables. No new `Resources.Load`, no direct asset
references that pull large content into memory on scene load.
- [x] **No new `GetComponent` / `AddComponent` where avoidable** — Where
unavoidable, the result is cached on a field, and any `GetComponent<T>`
is replaced with `TryGetComponent<T>(out var x)` — bare `GetComponent`
will be denied. `TryGetComponent` is the modern API (Unity 2019.2+) and
skips the Editor-only GC allocation `GetComponent` causes when a
component is missing: Unity wraps the `null` return in a managed "fake
null" object so its overloaded `==` operator can still detect destroyed
C++ objects, and constructing that wrapper allocates; `TryGetComponent`
returns a `bool` plus `out` parameter and never builds the wrapper. None
of these calls run inside `Update`, `LateUpdate`, `FixedUpdate`, jobs,
or other per-frame code paths.
- [x] **Per-frame work is scheduled through `BasisEventDriver`** — Any
new per-frame work hooks into `BasisEventDriver` rather than adding
standalone `Update` / `LateUpdate` / `FixedUpdate` callbacks on a
MonoBehaviour.
- [x] **Anything added to `BasisEventDriver` is bulletproof, or guarded
by `try`/`catch`** — `BasisEventDriver` runs the single per-frame tick
that drives the whole framework (network apply, local player sim,
blendshapes, JigglePhysics, nameplates, and more) as one sequential
chain. An unhandled exception anywhere in that chain aborts the rest of
the tick, so every step after the throwing one is silently skipped for
that frame. New work added to the driver must either be guaranteed not
to throw, or be wrapped in a `try`/`catch` that contains the failure and
surfaces it through `BasisDebug` — logged once / rate-limited, never
every frame (see the existing `HVRBasisBuiltInAddresses.Simulate()`
guard for the pattern). Expect this to be scrutinized closely in review.
- [x] **Considered jobification** — I asked whether this work can be
moved to a Unity Job (Burst-compiled where possible). If it can, it is.
If it cannot, the reason is in **Notes**.
- [x] **No needless `{ get; set; }` properties or access lockdowns** —
Public fields are fine; Basis is meant to be read and modified freely,
so don't wall things off `private`/`internal` without a real reason.
Don't wrap a field in `{ get; set; }` when the accessors do nothing —
property accessors have a real performance cost vs direct field access,
and the lead maintainer prefers plain fields (or a method / setter-only
property when only the setter needs logic) over a noop-getter pair. For
`.Instance` singletons, callers reassigning `Type.Instance` is allowed;
if that would break your code, log a warning or throw — don't block the
assignment. Locking down access is not your call.
- [x] **Camera access goes through `BasisLocalCameraDriver`** — Code
that needs the local camera (transform, projection, rig data, etc.)
pulls it from `BasisLocalCameraDriver` rather than looking one up
itself. Don't roll a separate camera discovery path.
- [x] **Logging uses `BasisDebug`** — All new logging calls go through
`BasisDebug.Log` / `BasisDebug.LogWarning` / `BasisDebug.LogError` (with
an appropriate `LogTag`) instead of `UnityEngine.Debug.Log` /
`Debug.LogWarning` / `Debug.LogError`. `BasisDebug` routes through
Basis's tagged, color-coded logger and respects the project-wide
`LoggingDisabled` toggle so logging can be killed at runtime; bare
`Debug.Log` calls bypass that and will be denied.
- [x] **No scene-wide discovery for dependencies** — New code is
architected so it does not need `FindObjectOfType` / `FindObjectsOfType`
/ `GameObject.Find` / `FindGameObjectsWithTag` to locate what it depends
on. References are wired in — registered through an existing
manager/driver, injected at init, or passed in by the caller — rather
than discovered by scanning the scene at runtime. If a scene scan is
genuinely unavoidable, justify it under **Notes**.
- [x] **No allocations in hot paths** — Per-frame code (Update /
LateUpdate / FixedUpdate, simulation loops, jobs, anything called once
per frame or more) does not allocate. No `new` on reference types, no
LINQ, no `string` concatenation/interpolation, no boxing, no `foreach`
over interface-typed collections. Allocate once at init and reuse the
buffer.
- [x] **No debugging in hot paths** — No log calls of any kind on
per-frame paths, including `BasisDebug`. Hot-path logging floods the
console and incurs cost on every frame regardless of whether the message
is filtered out downstream. If a hot-path log is needed while iterating,
gate it behind `#if UNITY_EDITOR` and remove (or leave gated) before
merge.
- [x] **Hot-path collection access is optimized** — Cache `.Count`
(lists) / `.Length` (arrays) into a local `int` before the loop instead
of re-reading the property each iteration. Prefer `T[]` (with a separate
length int when the array is over-sized) over `List<T>` where the data
is hot — Unity's mono BCL doesn't expose
`CollectionsMarshal.AsSpan(List<T>)`, so a list can't be fed into
`Span<T>` / unsafe paths cleanly. Where the perf justifies it, drop into
`Span<T>` / `ref` locals / `Unsafe.As` / `unsafe` pointer code to skip
bounds checks and copies, and call out the invariants you're relying on
under **Notes** so reviewers can sanity-check them.
<!-- required-checks-end -->

## Testing details
Tick the platforms you actually tested on. Leave the rest unticked —
these are informational and do not block merge.

- [x] Windows
- [ ] Linux
- [ ] Android
- [ ] iOS
- [ ] macOS

Input / control mode coverage:

- [ ] Tested in VR (note headset under **Notes**)
- [ ] Tested in desktop / non-VR mode
- [ ] Tested with phone controls (mobile touch input)
- [x] N/A — change does not touch player/XR/input code

Where applicable, confirm these flows still work after your changes:

- [ ] Hot-switching (desktop ↔ VR mode swap at runtime)
- [ ] Avatar swapping
- [ ] Server swapping (joining / leaving / changing servers)
- [x] N/A — change does not touch any of the above

## Notes
This is a **native-C-only** change (new `protocol/basis_hls.c/.h`, an
additive `.m3u8` branch in `basis_media_core.c`, a `CMakeLists.txt`
line, the rebuilt Windows x86_64 `basis_media_native.dll`, and README
docs). There is **no C# / MonoBehaviour / Unity-API code** in this PR,
so the C#-oriented required checks above — transform access,
Addressables, `GetComponent`, `BasisEventDriver`, jobification,
property/access style, `BasisLocalCameraDriver`, `BasisDebug` logging,
scene-wide discovery, hot-path allocations/logging/collection access —
are **N/A**; they're ticked per the "tick N/A boxes too" instruction.

The one hot path that does exist is the native background reader that
paces segment/part bytes to the demuxer. It runs entirely in C off the
Unity main thread, allocates its read-ahead buffer once at init and
reuses it, and is rate-limited to the stream's measured average bitrate
(with burst headroom for segment-start keyframes) so the present path is
fed at real time rather than flooded.

Tested on Windows against live HLS and LL-HLS origins; the ~5 s latency
target requires an LL-HLS origin (plain HLS gives its segment-bound
latency). Not exercised on Linux/macOS/Android/iOS — Android/Quest
support is planned as a follow-up.

Author: dooly123

Basis/Packages/com.basis.mediaplayer/Native~/CMakeLists.txt

@@ -67,6 +67,7 @@ set(CORE_SOURCES
     protocol/basis_rtmp.c
     protocol/basis_ts.c
     protocol/basis_mp4.c
+    protocol/basis_hls.c
 )
 
 # ---------------------------------------------------------------------------

Basis/Packages/com.basis.mediaplayer/Native~/basis_media_core.c

@@ -21,6 +21,7 @@
 #include "protocol/basis_ts.h"
 #include "protocol/basis_mp4.h"
 #include "protocol/basis_http.h"
+#include "protocol/basis_hls.h"
 
 #include <stdlib.h>
 #include <string.h>
@@ -192,6 +193,32 @@ static int ends_with_ci(const char* s, const char* suffix) {
     return 1;
 }
 
+/* HLS / LL-HLS: the URL is a playlist, not a continuous byte stream. The HLS
+ * source fetches+parses the M3U8, stitches segments (and LL-HLS parts) into one
+ * byte stream, and the existing TS/fMP4 demuxers consume it. Windows fetches via
+ * WinHTTP; Android/Quest support is planned. */
+static void run_hls(basis_media_engine_t* e) {
+#if defined(_WIN32)
+    basis_http_provider_t provider = {
+        basis_win_http_open, basis_win_http_read, basis_win_http_close
+    };
+    int is_fmp4 = 0;
+    void* hls = basis_hls_open(e->url, &provider, e->sink.is_running, e->sink.user, &is_fmp4);
+    if (!hls) {
+        basis_engine_set_error(e, "failed to open HLS playlist");
+        return;
+    }
+    basis_engine_set_state(e, BASIS_MEDIA_STATE_BUFFERING);
+    if (is_fmp4)
+        basis_mp4_run(&e->sink, basis_hls_read, hls);
+    else
+        basis_ts_run(&e->sink, basis_hls_read, hls);
+    basis_hls_close(hls);
+#else
+    basis_engine_set_error(e, "HLS playback currently requires the Windows backend.");
+#endif
+}
+
 static void run_http_like(basis_media_engine_t* e) {
     /* Android: the OS extractor can demux the URL itself (TLS included). */
     if (basis_decoder_try_open_url(e->decoder, e->url)) {
@@ -200,6 +227,13 @@ static void run_http_like(basis_media_engine_t* e) {
         return;
     }
 
+    /* HLS playlists are not a single continuous stream — hand off to the HLS
+     * source before the plain TS/fMP4 byte-source path. (.m3u8 may carry a query.) */
+    if (strstr(e->parts.path, ".m3u8")) {
+        run_hls(e);
+        return;
+    }
+
     void* src = NULL;
     basis_read_fn rd = NULL;