jlim
jlim

Reputation: 811

HTML video performance in Safari - repeated byte range requests

I have a page that displays a looping video and the performance of the playback appears less than ideal - the video stutters and lags instead of playing smoothly. I learned through a bit of searching that Safari handles streaming video differently than other browsers because it makes byte range requests and expects the server to respond with status 206. Safari makes a series of requests with a range header set, while Chrome is able to make a single request.

When I view the network requests in Safari dev tools, I see the series of byte range requests happening as expected. But when the video loops back and starts from the beginning, I see the same series of requests happening a second time and continuously.

JSFiddle to reproduce in Safari.

<video src="https://jsoncompare.org/LearningContainer/SampleFiles/Video/MP4/Sample-MP4-Video-File-Download.mp4" autoplay loop muted playsinline preload="auto" controls/>

enter image description here

Question is: is this by design? It seems inefficient that the browser is re-downloading the pieces of the video every time it plays. Performance wise, I suspect this is what is causing the non-smooth playback. Is caching supported for byte range requests in Safari?

I also suspect this behavior may have to do with the size of the asset. I see the described behavior for a video that’s ~40 MB but smaller videos are downloaded in two requests and the requests don’t repeat.

Helpful resources I came across

https://blog.logrocket.com/streaming-video-in-safari/ https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6

Upvotes: 4

Views: 3636

Answers (2)

Blackfaded
Blackfaded

Reputation: 416

I also think this is by design.
Recently I just implemented video streaming for a website and also saw this behaviour. In chrome and firefox everything just works fine and even with the bye-range headers it always requests little chunks.

The safari devtools state that it downloads big chunks and often aborts these requests. This is a very strange behaviour, especially when you proxy a video from a aws s3 or something like that. Because safari requests a large chunk, the server loads this chunk from the s3 and sends it back, but safari only needs a few bytes.

Here is a good article which goes into detail of this behaviour: https://www.stevesouders.com/blog/2013/04/21/html5-video-bytes-on-ios/

Upvotes: 1

Mick
Mick

Reputation: 25481

The re-requesting for the byte range requests is by design, or at least by current implementation.

It seems that the mechanism that Safari uses to cache requests does not currently allow for byte ranges - i.e. in simplistic terms, it looks just at the URL so would respond with whatever happened to be in cache for that URL, ignoring the byte range.

It seems this is a limitation (or maybe a very 'pure' interpretation of the specs, not sure...) but the current advice is definitely not to cache when using byte range requests on Apple based solutions:

NSURLRequestReloadIgnoringLocalCacheData = 1

This policy specifies that no existing cache data should be used to satisfy a URL load request.

Important Always use this policy if you are making HTTP or HTTPS byte-range requests.

(https://developer.apple.com/documentation/foundation/nsurlrequestcachepolicy/nsurlrequestreloadignoringlocalcachedata)

You can see more discussion on this here also in the Apple Developer forum: https://developer.apple.com/forums/thread/92119

Upvotes: 2

Related Questions