tauri: [bug] Asset protocol crashes app with large video files
Describe the bug
When seeking into longer/larger videos using Tauri’s asset protocol, the video will hang and eventually crash the app entirely.
After quite a bit of testing it seems that video size is what makes Tauri’s asset protocol crash the app. My original thinking was that it crashed due to the length of the video, but after generating a really long but small sized countdown video it worked fine. Then through more testing I found that videos larger than ~3.5 GiB crashed the asset protocol when seeking roughly 80% into the video, so when about ~3 GiB needed to be loaded.
Also from my testing it seems that Tauri’s asset protocol is seeking the entire video from start->seek point, which means that for longer/larger videos it takes a significant amount of time to seek into videos (from an SSD). The reason I think it’s seeking the entire video is due to how long the seeking takes on longer videos compared to when using a HTTP server to stream the file (instant seeking, compared to multiple seconds sometimes with Tauri’s asset protocol).
I doubt I’m running out of memory since my computer has 32GB of RAM to use. When looking at the task manger it crashes way before all my RAM is utilized. Tauri is using around 4GB of RAM before crashing.
I have tried using the streaming example, it gives the same result as the normal asset protocol.
When the app crashes nothing shows up in the Web DevTools or in the terminal running tauri dev. When running the app using RUST_BACKTRACE the app no longer crashes, instead the video tries to load endlessly but doesn’t cause a crash anymore.
Found temporary solution
When I found this issue with the asset protocol I decided to embed Rocket and use it to stream the videos, sadly it had the same issue, forcing me to use a Rocket responder that handled video streaming correctly. After a while I found rocket_seek_stream made by rydz. This fixed my issue and videos could now stream properly, seeking the video now doesn’t load from start->seek point, instead the video is only loaded from the seek point onwards. Even though I was able to workaround the issue, I would like for Tauri’s asset protocol to get fixed since I’d much rather not include Rocket in my project.
When using rocket_seek_stream with Rocket the app no longer crashes and seeking inside large videos is instant.
Crash demo
Reproduction
No response
Expected behavior
No response
Platform and versions
Environment
- OS: Windows 10.0.22621 X64
- Webview2: 110.0.1587.57
- MSVC:
- Visual Studio Build Tools 2022
- Visual Studio Community 2019
- Node.js: 18.14.2
- npm: 9.3.1
- pnpm: Not installed!
- yarn: Not installed!
- rustup: 1.24.3
- rustc: 1.66.1
- cargo: 1.66.1
- Rust toolchain: stable-x86_64-pc-windows-msvc
Packages
- @tauri-apps/cli [NPM]: 1.2.3
- @tauri-apps/api [NPM]: Not installed!
- tauri [RUST]: 1.2.4,
- tauri-build [RUST]: 1.2.1,
- tao [RUST]: 0.15.8,
- wry [RUST]: 0.23.4,
App
- build-type: bundle
- CSP: default-src ‘self’; style-src ‘self’ ‘unsafe-inline’; font-src ‘self’ data: *; img-src ‘self’ asset: https://asset.localhost; media-src stream: https://stream.localhost asset: https://asset.localhost
- distDir: …/src
- devPath: …/src
App directory structure ├─ .git ├─ .vscode ├─ node_modules ├─ src └─ src-tauri
Stack trace
No response
Additional context
I created a small repo that allows you to pick a local video to play (which crashes when seeking close to the end of larger files). I was not able to include a video file since the video file needs to be quite large (multiple GiBs), as such the project allows you to pick the video file to play. The video file should be 10GiB+ to reliably crash the app, in my testing ~3.5GiB is usually enough to crash it, but some larger video files still work (sometimes), as such 10GiB+ has always been a guaranteed crash for me.
The video used should be in a format supported by browsers (e.g. H264, VP9). H265 is not support since browsers do not have codec support for it.
In general the videos I’ve been trying to play that crash are Twitch VODs, since they are long and large (e.g. 8+ hours, 10GiB+).
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 23 (11 by maintainers)
Commits related to this issue
- fix(core): rewrite `asset` protocol streaming, closes #6375 — committed to tauri-apps/tauri by amrbashir a year ago
- fix(core): rewrite `asset` protocol streaming, closes #6375 (#6390) Co-authored-by: Lucas Nogueira <lucas@tauri.studio> — committed to tauri-apps/tauri by amrbashir a year ago
- fix(core): use `safe_block_on` fixes regression introduced in 45330e38193d0b2a01aa926aec433acc6b8f6597 ref: https://github.com/tauri-apps/tauri/issues/6375#issuecomment-1560063696 — committed to tauri-apps/tauri by amrbashir a year ago
- fix(core): use `safe_block_on` (#7047) fixes regression introduced in 45330e38193d0b2a01aa926aec433acc6b8f6597 ref: https://github.com/tauri-apps/tauri/issues/6375#issuecomment-1560063696 — committed to tauri-apps/tauri by amrbashir a year ago
- Merge remote-tracking branch 'origin/dev' into next (#7067) Co-authored-by: wusyong <wusyong@users.noreply.github.com> Co-authored-by: Fabian-Lars <fabianlars@fabianlars.de> Co-authored-by: Lucas N... — committed to tauri-apps/tauri by lucasfernog a year ago
I think I figured out the problem, could you apply this patch to your repro and see if it fixes the issue for your?
From my limited testing the current dev branch (#2317913b) works perfectly for video streaming, captions work as expected as well and seeking is instant. I will be doing a bit more extensive testing over the coming days and if I detect any issues I’ll be sure to report them.
Will the current dev branch be v1.4? If so, when could we be expecting a release (roughly)?
Thanks for the detailed bug report, I will see what I can do
Works like a charm now!
@yannkost thanks for the heads up, I opened #7047 to fix this
try adding the following in
Cargo.tomlthen run
cargo updateinsidesrc-tauriand test if still doesn’t work, please make a minimal repro@amrbashir thank you very much that seems to have fixed it ❤️
1.3 will not be having any more changes except for small hotfixes. That doesn’t mean that 1.3.1 can’t be far behind the 1.3 release.
Alright I’ll create a branch in the repo for the subtitle issue.