2020-10-26
2345
#chrome#safari
Ashley Davis
27471
Oct 26, 2020 â‹… 8 min read

Streaming video in Safari: Why is it so difficult?

Ashley Davis Ashley Davis is a software craftsman and author. He is VP of Engineering at Hone and currently writing Rapid Fullstack Development and the second edition of Bootstrapping Microservices. Follow on Twitter for updates.

Recent posts:

Leveraging Parallel Computing In Node.js

Leveraging parallel computing in Node.js

Use parallel computing in Node.js with worker threads to optimize performance, handle CPU-intensive tasks, and utilize multi-core processors.

David Omotayo
Feb 13, 2025 â‹… 8 min read

A guide to modern frontend architecture patterns

Frontend architecture is the foundation of your frontend codebase. Here’s how to optimize the pattern that you choose.

Shalitha Suranga
Feb 12, 2025 â‹… 9 min read
A Guide To Graceful Degradation In Web Development

A guide to graceful degradation in web development

Implement graceful degradation in frontend apps by handling failures, mitigating API timeouts, and ensuring a seamless UX with fallbacks.

Rosario De Chiara
Feb 11, 2025 â‹… 4 min read
Building High-Performance Websites Using Htmx And Go

Building high-performance websites using htmx and Go

Use htmx and Go to build high-performance websites, leveraging server-side rendering and minimal JavaScript for fast and efficient applications.

Abhinav Anshul
Feb 10, 2025 â‹… 11 min read
View all posts

10 Replies to "Streaming video in Safari: Why is it so difficult?"

  1. Hi, thank you for this blog, it is very helpful.
    It works perfectly with Safari (Mac), but not in Mobile Safari on ios (downloading the full video before starting to play…). Do you know why?

  2. Thanks for your feedback!

    That’s strange… the production version I’m using works although I never tested the code for the blog post. It might have been broken when I simplified it.

    Could you please log an issue against the code in GitHub, that will be an easier way to work through the problem, thanks.

    Ashley Davis

  3. I’ve encountered this problem with a web page I’m writing that shows videos. I’m doing the range queries correctly, but they still malfunction because the user shows first one video, then another. Your code assumes there’s only one video path, so it won’t work in this case. Range requests don’t include the file path. So how does the server code know which file to retrieve the bytes of data from? I tried using a session variable, but this fails because the session variable can change asynchronously with respect to what the video player is actually doing. The user can reposition and switch between a number of different videos! On Mac/Safari, this abnormally halts the video player.

  4. Range requests can have a route, they can have query parameters or they can have a body… so that’s at least three ways to statelessly include the file path or id of a video to play. Use which ever one best satisfies your needs.

  5. The problem doesn’t happen because of accept range requests (using the Accept-Ranges header), or for requests to open and play a video file. You are correct, all information from the server is available there.

    The problem happens for range requests from the client, which are made by the client application, such as a video player. These requests ARE ONLY MARKED by the HTTP_RANGE header. There is no other information that the server can use to locate the file whose bytes are to be returned to the client. This is one of the rare cases where a client calls a server to obtain information. Usually, it’s the other way around.

    This appears to be a very poor design, since multiple overlapping video displaying can be done by one server on behalf of one user. The bytes returned by the server may go to the wrong client player, which causes a crash of the player.

  6. YouTube works fine because it serves one video at a time. So its byte requests don’t need to specify which file is the context. When a client of mine tried to access a second video right after a first, the log showed that the byte requests were interleaved, probably due to lack of sync in setting the path in the Session variables. Anyway, when I look at the $_SERVER information for byte requests from the video player, the video path is NOT there, just the range of bytes.

  7. Ok maybe I’m misunderstanding something.

    But I just opened two browser windows and started two YouTube videos simultaneously. It was serving two videos simultaneously and seemed to have no problem. In fact I imagine that YouTube is serving millions of videos at once because that’s how many people are probably watching YouTube at the same time.

    If you want I can look at your code and see if I can spot a problem with it, just email me on [email protected]

  8. It is possible that my explanation is incorrect. The fact is that my code works for Firefox, Chrome, and Safari on a mobile device. It only fails for Safari on MacOS. It is a known bug with apparently no solution published as yet.

Leave a Reply