9b057a0030
The 4.x -> 5.x release folded `EventContext` into `Mpv` and made `wait_event` take `&mut self`, so the previous design (a single `Arc<Mpv>` shared between the message and event threads, with the event thread constructing its own `EventContext` from `mpv.ctx`) no longer compiles. Migration: - Build the main `Mpv` (with `wid`, `title`, etc.) and use it from the message thread for commands and `set_property`. - `create_client(None)` a sub-client `Mpv`, owned by the event thread, which calls `disable_deprecated_events`/`observe_property`/`wait_event` on itself. Global events (`EndFile`, `Shutdown`) and property changes observed by this client land in its event queue. - Replace the old `MpvExt::wake_up` (which woke the main `Mpv`) with an `EventClientWakeup` holding the sub-client's `mpv_handle` pointer, so the message thread can interrupt the event thread's blocking `wait_event` after pushing a new observe request onto the channel. Also removed the `PropertyData::Node(_)` match arm in `communication.rs`: 5.0.0 dropped `mpv_node` support, so the variant no longer exists and the match is exhaustive without it. https://claude.ai/code/session_01CuGHFREBZFkf8tfaiRV4K6 |
||
|---|---|---|
| .github/workflows | ||
| bin | ||
| bin-arm64 | ||
| images | ||
| mpv-arm64 | ||
| mpv-x64 | ||
| setup | ||
| src | ||
| .gitignore | ||
| build-arm64.ps1 | ||
| build.ps1 | ||
| build.rs | ||
| Cargo.lock | ||
| Cargo.toml | ||
| generate_descriptor.js | ||
| libmpv-2_arm64.zip | ||
| libmpv-2_x64.zip | ||
| README.md | ||
| rust-toolchain.toml | ||
| server.js | ||
| stremiover.js | ||
| upload.ps1 | ||
Stremio shell: new gen
A Windows-only shell using WebView2 and MPV
Goals:
- Performance
- Reliability
- Easy to ship
In all three, this architecture excels the Qt-based shell: it is about 2-5x more efficient depending on the use case, as it allows MPV to render directly in the window through it's optimal video output rather than using libmpv to integrate with Qt.
This is due to Qt having a complex rendering pipeline involving ANGLE and multiple levels of composing and drawing to textures, which inhibits full HW acceleration.
Meanwhile in this setup MPV uses whichever pipeline it considers to be optimal (like the mpv desktop app), which is normally d3d11, allowing full HW acceleration.
For web rendering, we use the native WebView2, which is Chromium based but shipped as a part of Windows 10: therefore we do not need to ship our own "distribution" of Chromium.
Finally, this should be a lot more reliable as it uses a much simpler and more native overall architecture.