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

[amrbashir]

I tried reproducing the issue but got CORS issue. I am heading out for today, if you can update the repro to include a subtitle file usage, I will check it out tomorrow.

[mauritzn]

Alright I'll create a branch in the repo for the subtitle issue.

[mauritzn]

Here is the new repo branch: tauri-asset-bug > subtitle-issue

[chippers]

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.

[amrbashir]

@mauritzn sorry for the delay, I updated the implementation above to fix the subtitle issue. The problem I was pre-allocating the buffer and filling it with 0 -> vec![0; len] when instead I should just call Vec::with_capacity(len)

[mauritzn]

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

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

[yannkost]

I have tried out the solution implemented by @amrbashir and on my side, the video at first loads quickly. But jumping on different points does still make the app crash with a exit code of 1. (Guess I have to figure out, how to debug this?) Also, after a certain number of requests, the time to handle a request for a new range of the video stream takes up over 30s. I simply wanted to add that the solution works, but only for a while in my case.

[amrbashir]

@yannkost were you testing using the above snippet, or the PR linked to this issue? Could you make a minimal repro so I can test it?

[yannkost]

@amrbashir I took the snipped posted above. (Also tested the snipped from the streaming example). I can try to make a minimal repo to test. I do not know how to update to my version to a PR version? Also, for some better error analyses, I wanted to debut the reason why Tauri crashed, but "set RUST_BACKTRACE=1" does not change the output of the terminal when running the project in development, maybe someone can point me into the right direction to get a full log? (I only managed to find a Windows event journal entry which gives not much info...)

[amrbashir]

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

[yannkost]

Sadly the "fix/asset-protocol-streaming" branch has been merged into "dev" already. But when I try to do it with the "dev" branch, I get a direct crash with following error message:

  thread 'main' panicked at 'Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.', C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\scheduler\multi_thread\mod.rs:65:25
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\std\src\panicking.rs:584
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src\panicking.rs:142
   2: tokio::runtime::context::enter_runtime
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\context.rs:183
   3: tokio::runtime::scheduler::multi_thread::MultiThread::block_on<core::future::from_generator::GenFuture<enum$<tauri::asset_protocol::asset_protocol_handler::async_block_env$0> > >
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\scheduler\multi_thread\mod.rs:65
   4: tokio::runtime::runtime::Runtime::block_on<core::future::from_generator::GenFuture<enum$<tauri::asset_protocol::asset_protocol_handler::async_block_env$0> > >
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\runtime.rs:304
   5: enum$<tauri::async_runtime::Runtime, Tokio>::block_on<core::future::from_generator::GenFuture<enum$<tauri::asset_protocol::asset_protocol_handler::async_block_env$0> > >  
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri\src\async_runtime.rs:126
   6: tauri::async_runtime::GlobalRuntime::block_on<core::future::from_generator::GenFuture<enum$<tauri::asset_protocol::asset_protocol_handler::async_block_env$0> > >
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri\src\async_runtime.rs:71
   7: tauri::async_runtime::block_on<core::future::from_generator::GenFuture<enum$<tauri::asset_protocol::asset_protocol_handler::async_block_env$0> > >
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri\src\async_runtime.rs:264
   8: tauri::asset_protocol::asset_protocol_handler
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri\src\asset_protocol.rs:49
   9: tauri::manager::impl$2::prepare_pending_window::closure$1<tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> > >
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri\src\manager.rs:503
  10: tauri_runtime::window::impl$2::register_uri_scheme_protocol::closure$0<enum$<tauri::EventLoopMessage>,tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> >,str,tauri::manager::impl$2::prepare_pending_window::closure_env$1<tauri_runtime_wry::Wry<enum$<ta
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri-runtime\src\window.rs:339
  11: alloc::boxed::impl$46::call<tuple$<ref$<tauri_runtime::http::request::Request> >,dyn$<core::ops::function::Fn<tuple$<ref$<tauri_runtime::http::request::Request> >,assoc$<Output,enum$<core::result::Result<tauri_runtime::http::response::Response,alloc::boxe
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\alloc\src\boxed.rs:1949
  12: tauri_runtime_wry::create_webview::closure$2<enum$<tauri::EventLoopMessage> >
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri-runtime-wry\src\lib.rs:3135
  13: alloc::boxed::impl$46::call<tuple$<ref$<http::request::Request<alloc::vec::Vec<u8,alloc::alloc::Global> > > >,dyn$<core::ops::function::Fn<tuple$<ref$<http::request::Request<alloc::vec::Vec<u8,alloc::alloc::Global> > > >,assoc$<Output,enum$<core::result::
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\alloc\src\boxed.rs:1949
  14: wry::webview::webview2::impl$1::init_webview::closure$6
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\wry-0.24.3\src\webview\webview2\mod.rs:587
  15: alloc::boxed::impl$45::call_mut<tuple$<enum$<core::option::Option<webview2_com_sys::Microsoft::Web::WebView2::Win32::ICoreWebView2>, 1, 18446744073709551615, Some>,enum$<core::option::Option<webview2_com_sys::Microsoft::Web::WebView2::Win32::ICoreWebView2
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\alloc\src\boxed.rs:1942
  16: webview2_com::callback::impl$329::Invoke
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\webview2-com-0.19.1\src\callback.rs:302
  17: webview2_com_sys::Microsoft::Web::WebView2::Win32::impl$2513::new::Invoke<webview2_com::callback::WebResourceRequestedEventHandler_Impl,webview2_com::callback::WebResourceRequestedEventHandler,-2>
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\webview2-com-sys-0.19.0\src\Microsoft\Web\WebView2\Win32\mod.rs:65767
  18: CreateWebViewEnvironmentWithOptionsInternal
  19: CreateWebViewEnvironmentWithOptionsInternal
  20: CreateWebViewEnvironmentWithOptionsInternal
  21: CreateWebViewEnvironmentWithOptionsInternal
  22: CreateWebViewEnvironmentWithOptionsInternal
  23: CreateWebViewEnvironmentWithOptionsInternal
  24: CreateWebViewEnvironmentWithOptionsInternal
  25: CreateWebViewEnvironmentWithOptionsInternal
  26: GetHandleVerifier
  27: telemetry_client::IDataFieldVisitor::IDataFieldVisitor
  28: DllCanUnloadNow
  29: telemetry_client::IDataFieldVisitor::IDataFieldVisitor
  30: DllCanUnloadNow
  31: GetHandleVerifier
  32: GetHandleVerifier
  33: GetHandleVerifier
  34: GetHandleVerifier
  35: GetHandleVerifier
  36: DllCanUnloadNow
  37: DllCanUnloadNow
  38: GetHandleVerifier
  39: DllCanUnloadNow
  40: DllCanUnloadNow
  41: DllCanUnloadNow
  42: GetHandleVerifier
  43: GetHandleVerifier
  44: DllCanUnloadNow
  45: DispatchMessageW
  46: DispatchMessageW
  47: windows::Windows::Win32::UI::WindowsAndMessaging::DispatchMessageW
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\windows-0.39.0\src\Windows\Win32\UI\WindowsAndMessaging\mod.rs:2671
  48: tao::platform_impl::platform::event_loop::EventLoop<enum$<tauri_runtime_wry::Message<enum$<tauri::EventLoopMessage> > > >::run_return<enum$<tauri_runtime_wry::Message<enum$<tauri::EventLoopMessage> > >,tauri_runtime_wry::impl$47::run::closure_env$0<enum$<
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tao-0.16.2\src\platform_impl\windows\event_loop.rs:264
  49: tao::platform_impl::platform::event_loop::EventLoop<enum$<tauri_runtime_wry::Message<enum$<tauri::EventLoopMessage> > > >::run<enum$<tauri_runtime_wry::Message<enum$<tauri::EventLoopMessage> > >,tauri_runtime_wry::impl$47::run::closure_env$0<enum$<tauri::
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tao-0.16.2\src\platform_impl\windows\event_loop.rs:218
  50: tao::event_loop::EventLoop<enum$<tauri_runtime_wry::Message<enum$<tauri::EventLoopMessage> > > >::run<enum$<tauri_runtime_wry::Message<enum$<tauri::EventLoopMessage> > >,tauri_runtime_wry::impl$47::run::closure_env$0<enum$<tauri::EventLoopMessage>,tauri::
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tao-0.16.2\src\event_loop.rs:179
  51: tauri_runtime_wry::impl$47::run<enum$<tauri::EventLoopMessage>,tauri::app::impl$18::run::closure_env$0<tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> >,tauri::app::impl$19::run::closure_env$0<tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> >,
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri-runtime-wry\src\lib.rs:2190
  52: tauri::app::App<tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> > >::run<tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> >,tauri::app::impl$19::run::closure_env$0<tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> >,tauri_utils::assets::Emb
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri\src\app.rs:875
  53: tauri::app::Builder<tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> > >::run<tauri_runtime_wry::Wry<enum$<tauri::EventLoopMessage> >,tauri_utils::assets::EmbeddedAssets>
             at C:\Users\User\.cargo\git\checkouts\tauri-9dcc2f9152472c1a\359058c\core\tauri\src\app.rs:1725
  54: app::main::async_block$0
             at .\src\main.rs:50
  55: core::future::from_generator::impl$1::poll<enum$<app::main::async_block_env$0> >
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\future\mod.rs:91
  56: tokio::runtime::park::impl$4::block_on::closure$0<core::future::from_generator::GenFuture<enum$<app::main::async_block_env$0> > >
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\park.rs:283
  57: tokio::runtime::coop::with_budget
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\coop.rs:107
  58: tokio::runtime::coop::budget
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\coop.rs:73
  59: tokio::runtime::park::CachedParkThread::block_on<core::future::from_generator::GenFuture<enum$<app::main::async_block_env$0> > >
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\park.rs:283
  60: tokio::runtime::context::BlockingRegionGuard::block_on<core::future::from_generator::GenFuture<enum$<app::main::async_block_env$0> > >
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\context.rs:315
  61: tokio::runtime::scheduler::multi_thread::MultiThread::block_on<core::future::from_generator::GenFuture<enum$<app::main::async_block_env$0> > >
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\scheduler\multi_thread\mod.rs:66
  62: tokio::runtime::runtime::Runtime::block_on<core::future::from_generator::GenFuture<enum$<app::main::async_block_env$0> > >
             at C:\Users\User\.cargo\registry\src\github.aaakk.us.kg-1ecc6299db9ec823\tokio-1.28.1\src\runtime\runtime.rs:304
  63: app::main
             at .\src\main.rs:50
  64: core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\ops\function.rs:248
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[0523/220728.242:ERROR:window_impl.cc(119)] Failed to unregister class Chrome_WidgetWin_0. Error = 0  

Does anybody know if there have been other changes in dev that could have provoked this?
I'm not really good at rust, as I'm still learning the basics. What I can say is that my tauri app launches the tokio runtime. There have been no problems with tokio before the update to the latest dev branch.

#[tokio::main]
async fn main() {
...
}

[amrbashir]

@yannkost thanks for the heads up, I opened #7047 to fix this

[mauritzn]

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)?

[yannkost]

Works like a charm now!