[GStreamer] Cannot play mp4 videos in Element: Received unexpected 200 HTTP status code for range request

[philn]

e14eade

[GStreamer] Cannot play mp4 videos in Element: Received unexpected 200 HTTP status code for range request
https://bugs.webkit.org/show_bug.cgi?id=221622

Reviewed by NOBODY (OOPS!).

https://tools.ietf.org/id/draft-ietf-httpbis-p5-range-09.html#header.content-range
If the server ignores a byte - range - spec because it is syntactically invalid, the
server SHOULD treat the request as if the invalid Range header field did not
exist. Normally, this means return a 200 response containing the full entity.

* Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:
(CachedResourceStreamingClient::responseReceived):

e14eade

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	❌ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🛠 gtk
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🧪 gtk-wk2
	✅ 🧪 api-ios	✅ 🧪 mac-wk2	❌ 🧪 api-gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2
	✅ 🛠 tv-sim
	✅ 🛠 watch
	✅ 🛠 watch-sim

[webkit-early-warning-system]

EWS run on current version of this PR (hash e14eade)

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	❌ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🛠 gtk
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🧪 gtk-wk2
	✅ 🧪 api-ios	✅ 🧪 mac-wk2	❌ 🧪 api-gtk
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2
	✅ 🛠 tv-sim
	✅ 🛠 watch
	✅ 🛠 watch-sim

[calvaris]

I think @ntrrgc had an opinion about this.

[ntrrgc]

Safari doesn't support media from servers without Content-Range support. Content-Range is needed for reasonable seek support. To support media without Content-Range it's necessary to store the entire file in memory, and a seek to time can only be implemented by downloading the entire file from the start.

[ntrrgc]

If you really want to support servers without Content-Range support, the following issues need to be addressed:

1. If any RAM or file system cache is used, there must be a relatively small file size limit under which playback will be refused (if the server declares Content-Length) or aborted (if the server doesn't declare Content-Length but such length is reached). This must be communicated to users and developers through the browser console.
2. The pipeline must ensure no further seeks are sent to the source element. Instead, seeks to the future must be satisfied by waiting until buffering reaches the requested position, and seeks to the past must be satisfied from cached media. Otherwise, casual generous seeking from users would be very unresponsive and consume a lot of unnecessary network data.

[philn]

Safari doesn't support media from servers without Content-Range support.

Are you sure about this?

[ntrrgc]

Safari doesn't support media from servers without Content-Range support.

Are you sure about this?

Yes, pretty much. For instance: https://stephenweiss.dev/safari-streaming-video

[eric-carlson]

Safari doesn't support media from servers without Content-Range support.

Are you sure about this?

Yes, pretty much. For instance: https://stephenweiss.dev/safari-streaming-video

While the Apple media frameworks WebKit uses require Content-Range support, WebKit now works around this when loading data from servers without support by synthesizing range requests. See for example https://github.com/WebKit/WebKit/blob/main/Tools/TestWebKitAPI/Tests/WebKitCocoa/MediaLoading.mm

[ntrrgc]

@eric-carlson What do you mean with synthesizing range requests? I see a RangeRequestSynthesisWithoutContentLength test that removes the Content-Length header. Is the purpose of that make WebKit believe the content is a live stream and therefore shouldn't receive seeks?