docs(specs): record the Linux native-video compositing spike
🏗️ Build and Test JellyTau / Run Tests (pull_request) Successful in 15m3s
🏗️ Build and Test JellyTau / Supply Chain (pull_request) Successful in 38s
Traceability Validation / Check Requirement Traces (pull_request) Successful in 20s
🏗️ Build and Test JellyTau / Android Compile Check (pull_request) Successful in 4m11s
🏗️ Build and Test JellyTau / Run Tests (pull_request) Successful in 15m3s
🏗️ Build and Test JellyTau / Supply Chain (pull_request) Successful in 38s
Traceability Validation / Check Requirement Traces (pull_request) Successful in 20s
🏗️ Build and Test JellyTau / Android Compile Check (pull_request) Successful in 4m11s
Adds the spike write-up and re-opens finding 2 of playback-backend-unification.md, which concluded that video cannot unify on a native engine because the webview owns the surface. That finding's general form has since been falsified on Android, where native video composites behind a transparent WebView and ships on by default. The evidence behind it was also entirely about foreign-window embedding -- mpv's render API, drawing into a GL context we own inside Tauri's own GTK tree, was never tested. The spike tests that one claim and comes back green on Linux for both X11 and Wayland, bar the Tauri default_vbox() half of G1. Findings 3-6 are deliberately left standing. Finding 3 in particular -- mpv has no adaptive bitrate -- is an independent disqualifier that a green compositing result does not clear, and the spike says so rather than reading as a green light. The next-free-id line moves to UR-079 / IR-033 / DR-219: this branch allocated UR-077 and UR-078 for the updater and diagnostics work, and DR-215 through DR-218 with them, after that line was last written. Authored in a parallel session working in the same checkout; committed here so it travels with the rest of the branch.
This commit is contained in:
@@ -90,6 +90,17 @@ The most recent comment on tauri#6343 (2026-05-23) confirms it is still unsolved
|
||||
**The principle to carry forward: audio can unify on a native engine; video
|
||||
cannot, because video needs a surface and the webview owns the surface.**
|
||||
|
||||
> **Re-opened on Linux (2026-08-21).** This finding's general form has since been
|
||||
> falsified on Android — native video now composites behind a transparent Tauri
|
||||
> WebView and ships on by default (see
|
||||
> [05-platform-backends.md](../architecture/05-platform-backends.md#native-video-compositing-android)).
|
||||
> The evidence above is also entirely about *foreign-window embedding*; mpv's
|
||||
> render API, drawing into a GL context we own inside Tauri's own GTK tree, was
|
||||
> never tested. [linux-native-video-spike.md](linux-native-video-spike.md) tests
|
||||
> that one claim on Linux. **Findings 3-6 below are untouched by it** - in
|
||||
> particular finding 3, which is an independent disqualifier a green spike would
|
||||
> not clear.
|
||||
|
||||
### 3. mpv would regress streaming quality
|
||||
|
||||
mpv has **no adaptive bitrate**. It delegates HLS to FFmpeg's demuxer, which
|
||||
|
||||
Reference in New Issue
Block a user