React (Vite) video

Not a single fetch of the whole file. Create a signed upload URL on a server, then upload in chunks from the browser so a dropped connection costs one chunk instead of the transfer.

Safari plays HLS natively and Chrome, Firefox and Edge do not, so a hand-rolled player carries two code paths and Hls.isSupported() returns false on the one you forget to test.

Because the effect that creates the player is re-running. React 18 StrictMode mounts every effect twice in development, so without a cleanup that calls destroy() you get two instances attached to one video element. A changing src does the same thing in production, which is what catches people refreshing a playback token.

You need somewhere to run one function, because the signed URL is created with a Secret Key and a key in the bundle is a published key. A Vite app has no server of its own, so that is a small endpoint or a serverless function.

Take the file out of the request. A chunked upload straight to storage has no single long-lived request to time out, and it resumes from the last confirmed byte after a network change rather than starting again.

react-player wraps sources such as YouTube and Vimeo and inherits each provider's behaviour. A hosted player plays your own adaptive stream and brings the parts you would otherwise assemble: quality levels, captions, signed playback and playback metrics.

Vite is fine. The only thing Next.js gives you here is a place to run the one server-side call, and in a Vite app you deploy that separately. Everything client-side, including the player and the uploader, is identical.

Set the media to a private access policy and create a short-lived JWT on your server, which the player takes as a token attribute. The link stops working when the token expires. DRM is the stronger option when capture itself is the threat.