search

tauri-apps / tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.
https://tauri.app
Apache License 2.0
83.94k stars 2.52k forks source link

[bug] MacOS Problem with playing video from resources in the format webm. #5605

Open Bukmopbl4 opened 1 year ago

Bukmopbl4 commented 1 year ago

Describe the bug

I noticed an unpleasant bug when loading video from resources in the format webm. The video takes a super long time to load thousands of requests byte by byte. Bytes range is abnormal like "Range: bytes=1010843-1010843". In Dev and Prod. Same Video in mp4 format is loaded with correct chunks and playing normally.

I used resolveResource and convertFileSrc.

https://user-images.githubusercontent.com/19820469/201137488-af07be82-e658-4b47-94aa-c9de33cf36bd.mp4

Reproduction

No response

Expected behavior

No response

Platform and versions

Environment › OS: Mac OS 13.0.0 X64 › Node.js: 16.17.1 › npm: 8.15.0 › pnpm: Not installed! › yarn: Not installed! › rustup: 1.25.1 › rustc: 1.64.0 › cargo: 1.64.0 › Rust toolchain: stable-x86_64-apple-darwin

Packages WARNING: no lock files found, defaulting to npm › @tauri-apps/cli [NPM]: 1.2.0 › @tauri-apps/api [NPM]: Not installed! › tauri [RUST]: 1.2.0, › tauri-build [RUST]: 1.2.0, › tao [RUST]: 0.15.2, › wry [RUST]: 0.22.0,

App › build-type: bundle › CSP: unset › distDir: ../src › devPath: ../src package.json not found

App directory structure ├─ src-tauri ├─ .git ├─ .vscode └─ src

Stack trace

No response

Additional context

No response

Bukmopbl4 commented 1 year ago

I think this is exclusively a problem of the custom protocol, since on local server http://127.0.0.1:1430/ it works without problems.

amrbashir commented 1 year ago

Seems to work fine on Windows, so I will mark this as a macOS issue.

when you are using a dev-server, is the range headers also weird?

Bukmopbl4 commented 1 year ago

when you are using a dev-server, is the range headers also weird?

image

I have a same problem on DEV

Bukmopbl4 commented 1 year ago

I tried to play the video as date link in base64 and it works with anything, but it doesn't work with webm format. Feeling that this is a problem specifically with playback in the format webm vp9 codec

Bukmopbl4 commented 1 year ago

Seems to work fine on Windows

On Windows, the video webm is played as needed from assets in any form and with transparency.

Bukmopbl4 commented 1 year ago

but if I use external link it loads with 2 requests and i can play video.

image

there is some problem if it is a video tag on the local page.

amrbashir commented 1 year ago

when you are using a dev-server, is the range headers also weird?

image

I have a same problem on DEV

I meant serving the file through a localhost server not through asset protocol

Bukmopbl4 commented 1 year ago
image

it works on DEV through a localhost server but without alpha-channel support like on Windows

Owez commented 1 year ago

Looks like im having the same issue at the moment, im serving webm files from an api to my app and it has really strange results (everything here is webm, for some reason only one video plays. these all work fine in firefox whilst using the dev server):

https://user-images.githubusercontent.com/30081702/221376074-0c055482-fb66-4b8c-a005-fedd8c766f8f.mov

@Bukmopbl4 Did you find a fix for your issue in the end?

Owez commented 1 year ago

I can confirm that its just the webm container format and nothing to do with the videos themselves. If you convert all input videos into mp4 (e.g., using ffmpeg) they work perfectly fine when streaming from a server. This is a decent workaround for now because copying the containers is relatively quick and won't destroy video quality.

My core library is in Python and luckily I already have a converter for input videos, so I just adapted it for mp4 files. Doing a simple container codac copying (like this) is all that's needed. Example converter here:

https://github.com/Owez/yark/blob/f67232073c2560a623b434b64734cf168d766a95/yark/yark/archiver/converter.py#L10

Bukmopbl4 commented 1 year ago

I can confirm that its just the webm container format and nothing to do with the videos themselves. If you convert all input videos into mp4 (e.g., using ffmpeg) they work perfectly fine when streaming from a server. This is a decent workaround for now because copying the containers is relatively quick and won't destroy video quality.

My core library is in Python and luckily I already have a converter for input videos, so I just adapted it for mp4 files. Doing a simple container codac copying (like this) is all that's needed. Example converter here:

https://github.com/Owez/yark/blob/f67232073c2560a623b434b64734cf168d766a95/yark/yark/archiver/converter.py#L10

mp4 does not have transparency support. webm (vp9) is required.