[bug] Asset protocol crashes app with large video files

[mauritzn]

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

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

• 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+).

[amrbashir]

Thanks for the detailed bug report, I will see what I can do

[amrbashir]

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;
 

[mauritzn]

That works perfectly @amrbashir, thank you. The initial load of the video is still a bit slower compared to using Rocket, but the seek times are now instant and long/large videos no longer hang and crash the app.

One concern I do have have though is the lack of an Access-Control-Allow-Origin header. This is a header that is pretty much required on video elements if you want to load subtitles (since crossorigin="anonymous" is used on video elements to fix sameorigin issue), but it's not included in the asset protocol nor in this stream protocol, I did add it manually to the code you provided to see if it worked like expected and it did. So would it be possible to get an Access-Control-Allow-Origin header added somehow as well?

Other than the small header concern, what would be the timeline for getting this fix added to Tauri?

[amrbashir]

The initial load of the video is still a bit slower compared to using Rocket

I will see what I can do about that but no promises on this one.

One concern I do have have though is the lack of an Access-Control-Allow-Origin header. This is a header that is pretty much required on video elements if you want to load subtitles (since crossorigin="anonymous" is used on video elements to fix sameorigin issue), but it's not included in the asset protocol nor in this stream protocol, I did add it manually to the code you provided to see if it worked like expected and it did. So would it be possible to get an Access-Control-Allow-Origin header added somehow as well?

In tauri's asset protocol, we set the Access-Control-Allow-Origin header to the window origin, I just left it out of the example above.

Other than the small header concern, what would be the timeline for getting this fix added to Tauri?

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

[mauritzn]

I will see what I can do about that but no promises on this one.

The initial load time isn't that extreme that it's a big issue, so if it cannot be improved, no worries. For context initial load time for a 7 hours long video file (18.4GB) is ~4 seconds using the provided solution, compared to ~2 seconds using Rocket with rocket_seek_stream.

In tauri's asset protocol, we set the Access-Control-Allow-Origin header to the window origin, I just left it out of the example above.

Ahh alright, great 🙂

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

Okay, well at least I have a temporary solution that allows me to finally ditch Rocket, so thank you again ❤️

[amrbashir]

PR is up now #6390

The initial load time isn't that extreme that it's a big issue, so if it cannot be improved, no worries. For context initial load time for a 7 hours long video file (18.4GB) is ~4 seconds using the provided solution, compared to ~2 seconds using Rocket with rocket_seek_stream.

I don't know but I have a 6gb- 3hours long file and the load is almost instant to me, I don't have a bigger file to test with so I will just ignore this issue for now until I have something to test with or others report the same.

Okay, well at least I have a temporary solution that allows me to finally ditch Rocket, so thank you again ❤️

You're welcome, I also updated the diff above to include the multipart implementation, should be fine to use until the fix is released to crates.io

[mauritzn]

I noticed an issue with the updated version, for subtitle files a bunch of NUL characters are added to the beginning of the streamed file and causes it to stop working.

Old version:

Update version:

[amrbashir]

Are the subtitle files embedded in the video, or separate? could you give me the request details?

[mauritzn]

Are the subtitle files embedded in the video, or separate?

They are stored as .vtt files separately from the video and are streamed using the <track> HTML element.

could you give me the request details?

No quite sure what all the details you want are. But here are the request headers:

---

For context the old version's request headers look the same, the only thing missing from the old version is content-length in the response headers.