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

https://user-images.githubusercontent.com/11979966/221927917-4f26e879-2950-49d2-b1f6-993d4882d15d.mp4

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

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

Most upvoted comments

I think I figured out the problem, could you apply this patch to your repro and see if it fixes the issue for your?

diff --git a/src-tauri/Cargo.toml b/src-tauri/Cargo.toml
index 6561691..2682f1f 100644
--- a/src-tauri/Cargo.toml
+++ b/src-tauri/Cargo.toml
@@ -17,6 +17,10 @@ tauri-build = { version = "1.2", features = [] }
 serde_json = "1.0"
 serde = { version = "1.0", features = ["derive"] }
 tauri = { version = "1.2", features = ["devtools", "dialog-open", "protocol-asset", "shell-open"] }
+percent-encoding = "2.2.0"
+url = "2.3.1"
+http-range-header = "0.3.0"
+rand = "0.8.5"
 
 [features]
 # by default Tauri runs in production mode
diff --git a/src-tauri/src/main.rs b/src-tauri/src/main.rs
index 3cd46c4..2ca41eb 100644
--- a/src-tauri/src/main.rs
+++ b/src-tauri/src/main.rs
@@ -3,9 +3,157 @@
     windows_subsystem = "windows"
 )]
 
+use std::io::{Read, Seek, SeekFrom, Write};
+use tauri::http::{
+    header::{ACCEPT_RANGES, CONTENT_LENGTH, CONTENT_RANGE, CONTENT_TYPE, RANGE},
+    status::StatusCode,
+    MimeType, ResponseBuilder,
+};
+use url::{Position, Url};
+
 fn main() {
     tauri::Builder::default()
         .invoke_handler(tauri::generate_handler![])
+        .register_uri_scheme_protocol("stream", move |_app, request| {
+            let parsed_path = Url::parse(request.uri())?;
+            let filtered_path = &parsed_path[..Position::AfterPath];
+            let path = filtered_path
+                .strip_prefix("stream://localhost/")
+                // the `strip_prefix` only returns None when a request is made to `https://tauri.$P` on Windows
+                // where `$P` is not `localhost/*`
+                .unwrap_or("");
+            let path = percent_encoding::percent_decode(path.as_bytes())
+                .decode_utf8_lossy()
+                .to_string();
+
+            let mut file = std::fs::File::open(&path)?;
+
+            // get current position
+            let old_pos = file.seek(SeekFrom::Current(0))?;
+            // get file len
+            let len = file.seek(SeekFrom::End(0))?;
+            // reset position
+            file.seek(SeekFrom::Start(old_pos))?;
+
+            // get the mime type
+            let mut prelude: [u8; 256] = [0; 256];
+            file.read(&mut prelude)?;
+            let mime_type = MimeType::parse(&prelude, &path);
+
+            // reset position
+            file.seek(SeekFrom::Start(0))?;
+
+            let mut resp = ResponseBuilder::new().header(CONTENT_TYPE, &mime_type);
+
+            let response = if let Some(x) = request.headers().get(RANGE) {
+                let not_satisfiable = || {
+                    ResponseBuilder::new()
+                        .status(StatusCode::RANGE_NOT_SATISFIABLE)
+                        .header(CONTENT_RANGE, format!("bytes */{len}"))
+                        .body(vec![])
+                };
+
+                resp = resp.header(ACCEPT_RANGES, "bytes");
+
+                let ranges = http_range_header::parse_range_header(x.to_str()?)?;
+                let ranges = ranges.validate(len);
+                let ranges: Vec<_> = if let Ok(x) = ranges {
+                    x.iter().map(|r| (*r.start(), *r.end())).collect()
+                } else {
+                    return not_satisfiable();
+                };
+
+                const MAX_LEN: u64 = 1000 * 1024;
+
+                if ranges.len() == 1 {
+                    let &(start, mut end) = ranges.first().unwrap();
+
+                    if start >= len || end >= len || end < start {
+                        return not_satisfiable();
+                    }
+
+                    // adjust end byte for MAX_LEN
+          			 end = start + (end - start).min(len - start).min(MAX_LEN - 1);
+
+          			 // calculate number of bytes needed to be read
+          			 let bytes_to_read = end + 1 - start;
+
+          			 // allocate a buf with a suitable capacity
+          			 let mut buf = Vec::with_capacity(bytes_to_read as usize);
+          			 // seek the file to the starting byte
+          			 file.seek(SeekFrom::Start(start))?;
+          			 // read the needed bytes
+          			 file.take(bytes_to_read).read_to_end(&mut buf)?;
+
+                    resp = resp.header(CONTENT_RANGE, format!("bytes {start}-{end}/{len}"));
+                    resp = resp.header(CONTENT_LENGTH, end + 1 - start);
+                    resp = resp.status(StatusCode::PARTIAL_CONTENT);
+                    resp.body(buf)
+                } else {
+                    let mut buf = Vec::new();
+                    let ranges = ranges
+                        .iter()
+                        .filter_map(|&(start, mut end)| {
+                            if start >= len || end >= len || end < start {
+                                None
+                            } else {
+                                end = start + (end - start).min(len - start).min(MAX_LEN - 1);
+                                Some((start, end))
+                            }
+                        })
+                        .collect::<Vec<_>>();
+
+                    let boundary = random_boundary();
+                    let boundary_sep = format!("\r\n--{boundary}\r\n");
+                    let boundary_closer = format!("\r\n--{boundary}\r\n");
+
+                    resp = resp.header(
+                        CONTENT_TYPE,
+                        format!("multipart/byteranges; boundary={boundary}"),
+                    );
+
+                    for (end, start) in ranges {
+                        // a new range is being written, write the range boundary
+                        buf.write_all(boundary_sep.as_bytes())?;
+
+                        // write the needed headers `Content-Type` and `Content-Range`
+                        buf.write_all(format!("{CONTENT_TYPE}: {mime_type}\r\n").as_bytes())?;
+                        buf.write_all(
+                            format!("{CONTENT_RANGE}: bytes {start}-{end}/{len}\r\n").as_bytes(),
+                        )?;
+
+                        // write the separator to indicate the start of the range body
+                        buf.write_all("\r\n".as_bytes())?;
+
+               	     // calculate number of bytes needed to be read
+                        let bytes_to_read = end + 1 - start;
+
+                        let mut local_buf = vec![0_u8; bytes_to_read as usize];
+                        file.seek(SeekFrom::Start(start))?;
+                        file.read_exact(&mut local_buf)?;
+                        buf.extend_from_slice(&local_buf);
+                    }
+                    // all ranges have been written, write the closing boundary
+                    buf.write_all(boundary_closer.as_bytes())?;
+
+                    resp.body(buf)
+                }
+            } else {
+                let mut buf = Vec::with_capacity(len as usize);
+                file.read_to_end(&mut buf)?;
+                resp = resp.header(CONTENT_LENGTH, len);
+                resp.body(buf)
+            };
+
+            response
+        })
         .run(tauri::generate_context!())
         .expect("error while running tauri application");
 }
+
+fn random_boundary() -> String {
+    use rand::RngCore;
+
+    let mut x = [0 as u8; 30];
+    rand::thread_rng().fill_bytes(&mut x);
+    (&x[..])
+        .iter()
+        .map(|&x| format!("{:x}", x))
+        .fold(String::new(), |mut a, x| {
+            a.push_str(x.as_str());
+            a
+        })
+}
diff --git a/src/main.js b/src/main.js
index 4064b3a..fc841fc 100644
--- a/src/main.js
+++ b/src/main.js
@@ -25,6 +25,7 @@ window.addEventListener("DOMContentLoaded", () => {
               const assetPath = convertFileSrc(selected);
 
               let videoElement = document.createElement("video");
+              +videoElement.setAttribute("autoplay", "");
               videoElement.setAttribute("controls", "");
               videoElement.src = assetPath;
 

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.toml

[patch.crates-io]
tauri = { git = "https://github.com/tauri-apps/tauri", branch = "fix/asset-protocol-streaming" }

then run cargo update inside src-tauri and test if still doesn’t work, please make a minimal repro

@amrbashir thank you very much that seems to have fixed it ❤️

Tested: small video, small video with subtitle, large video, large video with subtitle

Hard to say tbh, tauri 1.3 is already in internal auditing so It may wait for 1.4 or 1.3.1. I will make the PR today but it is not up to me to include it in 1.3 or not, cc @chippers

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.