dtourolle
2f637d4775
mpv has never decoded a video frame in this app: the backend sets `video: no` unconditionally, because Linux video has always been the webview's job and decoding it twice would burn a core for a picture nobody sees. The render path built in the previous commit therefore had nothing to draw. With native video on, mpv is configured for video *and* `vo=libmpv` — the render API only works through that output, and the default would try to open a window of its own. Set at construction, because mpv resolves its video output when it initialises and flipping the property later does not re-open one. The flag lives in `player::native_video`, read by all three things that must agree: the backend (configured before anything plays), the surface (nothing to draw otherwise), and `get_player_status` (which tells the frontend whether to use a `<video>` element — two decoders on one stream would fight over the audio). A function rather than three `env::var` checks, because a capability answered in several places is a capability whose answers drift: four separate bugs this cycle came from exactly that shape. Also fixes an ordering bug the first run exposed. The surface was attached in `setup` before the player backend was constructed, and the mpv handle is registered *during* that construction — so it found nothing every time and logged "no mpv handle". Attaching after the backend exists is the whole fix. Confirmed on a real run: mpv accepts `vo=libmpv`, the GL context comes up on Tauri's vbox, and `mpv_render_context_create` succeeds — which also proves the libepoxy data-symbol handling is right, since a wrong `get_proc_address` would have taken SIGSEGV on the first GL call rather than returning cleanly. No frame has reached the screen yet. The webview is still opaque, so it will paint over anything drawn beneath it until transparency is set up. Security: quick-xml 0.38.4 carried RUSTSEC-2026-0194 (quadratic parse on duplicate attribute names) and RUSTSEC-2026-0195 (unbounded namespace allocation, memory-exhaustion DoS). `cargo deny` gates CI on advisories, so this would have failed the next release. Fixed by plist 1.8 -> 1.10, which pulls quick-xml 0.41. Licences, bans and sources still pass. UT-216 pins the flag's parsing: absent, empty, `0`, `no` and anything unrecognised all mean off. A half-set variable that half-enabled the renderer would configure mpv for video with nothing drawing it — audio over a black rectangle. Also removes a wall-clock timer from the waitForRepository late-arrival test, which failed once under load. The assertion is about ordering, so it now publishes on a microtask and cannot race.
79 lines
3.0 KiB
Rust
79 lines
3.0 KiB
Rust
//! Whether this process renders video natively, answered once.
|
|
//!
|
|
//! Three things need this and must agree: the mpv backend (which has to be
|
|
//! configured for video *at construction*, before anything plays), the video
|
|
//! surface (which has nothing to draw otherwise), and `get_player_status`
|
|
//! (which tells the frontend whether to use a webview `<video>` element).
|
|
//!
|
|
//! It is a function rather than three `env::var` checks for the reason this
|
|
//! codebase keeps rediscovering: a capability answered in several places is a
|
|
//! capability whose answers drift. Four separate bugs this cycle came from
|
|
//! exactly that shape — a webview's decode limits applied to ExoPlayer, a
|
|
//! transcode target contradicting a direct-play claim, a codec list hardcoded in
|
|
//! a URL builder. One source, read by everyone.
|
|
//!
|
|
//! TRACES: UR-080 | DR-231, DR-235
|
|
|
|
/// The opt-in for native desktop video.
|
|
///
|
|
/// Off by default while the render path is unproven — the webview path still
|
|
/// works and is what ships. This becomes the *default* (and then the only path)
|
|
/// when DR-235 lands; the variable is how it is exercised until then.
|
|
const ENV_FLAG: &str = "JELLYTAU_NATIVE_VIDEO";
|
|
|
|
/// Whether mpv should decode and draw video in this process.
|
|
///
|
|
/// Read fresh rather than cached: it is consulted a handful of times at startup,
|
|
/// and a `OnceLock` here would only make it harder to test.
|
|
///
|
|
/// TRACES: UR-080 | DR-231, DR-235
|
|
pub fn enabled() -> bool {
|
|
// Only where a native renderer exists. On Android ExoPlayer already does
|
|
// this and `use_html5_element` is false for entirely separate reasons.
|
|
if !cfg!(all(target_os = "linux", not(target_os = "android"))) {
|
|
return false;
|
|
}
|
|
matches!(
|
|
std::env::var(ENV_FLAG).as_deref(),
|
|
Ok("1") | Ok("true") | Ok("yes")
|
|
)
|
|
}
|
|
|
|
#[cfg(test)]
|
|
mod tests {
|
|
use super::*;
|
|
|
|
/// Absent, empty, or anything unrecognised means off. A half-set variable
|
|
/// must not half-enable a renderer — the failure mode would be mpv
|
|
/// configured for video with nothing drawing it, i.e. audio playing over a
|
|
/// black rectangle.
|
|
///
|
|
/// TRACES: UR-080 | DR-231 | UT-216
|
|
#[test]
|
|
fn test_only_explicit_truthy_values_enable_it() {
|
|
let restore = std::env::var(ENV_FLAG).ok();
|
|
|
|
for value in ["", "0", "no", "false", "maybe", "2"] {
|
|
std::env::set_var(ENV_FLAG, value);
|
|
assert!(!enabled(), "{value:?} must not enable native video");
|
|
}
|
|
|
|
for value in ["1", "true", "yes"] {
|
|
std::env::set_var(ENV_FLAG, value);
|
|
assert_eq!(
|
|
enabled(),
|
|
cfg!(all(target_os = "linux", not(target_os = "android"))),
|
|
"{value:?} enables it exactly where a native renderer exists"
|
|
);
|
|
}
|
|
|
|
std::env::remove_var(ENV_FLAG);
|
|
assert!(!enabled(), "absent means off");
|
|
|
|
match restore {
|
|
Some(v) => std::env::set_var(ENV_FLAG, v),
|
|
None => std::env::remove_var(ENV_FLAG),
|
|
}
|
|
}
|
|
}
|