Summary: | iOS / iPadOS 15 video playback performance regression after seek | ||
---|---|---|---|
Product: | WebKit | Reporter: | Dustin Kerstein <dustin.kerstein> |
Component: | Media | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED MOVED | ||
Severity: | Major | CC: | dustin.kerstein, jer.noble, webkit-bug-importer |
Priority: | P1 | Keywords: | InRadar |
Version: | Other | ||
Hardware: | iPhone / iPad | ||
OS: | Unspecified |
Description
Dustin Kerstein
2021-08-23 11:24:24 PDT
Upon further testing, it appears this issue may be more of an iOS / iPadOS issue as it can be replicated in the native video player, not just Safari. Is it possible to loop in the Apple iOS/iPadOS folks? (and closing this because per your investigation this isn't actually a WebKit bug) FYI, here are the related feedback assistant bugs. FB9688897 FB9666426 FB9554184 Some of these issues may be more in VideoToolbox than in WebKit. And a post on the Apple Developer Forums - https://developer.apple.com/forums/thread/693002 One of the requirements for media playback on iOS and macOS is that the server responds to requests with a valid Range: header with a 206 response and a well formed Content-Range: response header. And this URL will give out a 200 response for a Range request... sometimes. Here's the output of curling that file with a 2-byte range twice in a row: ...> curl -I -r 0-1 https://files.panomoments.com/bbb_sunflower_2160p_60fps_normal.mp4; curl -I -r 0-1 https://files.panomoments.com/bbb_sunflower_2160p_60fps_normal.mp4 HTTP/2 200 date: Mon, 25 Oct 2021 23:10:23 GMT content-type: video/mp4 content-length: 673223862 x-amz-id-2: XgpLClM0fxhLvc8mY6myO+G9hj66UnxBXcOVtvYSfwxLMG1fPvd4AyYynbYODF4Xvabx5acSc/E= x-amz-request-id: 6EYV634TXT20SEX4 last-modified: Fri, 01 May 2020 15:20:57 GMT etag: "68360a312337530961dd70c330199fda-40" cache-control: max-age=31536000 cf-cache-status: MISS expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=AvVUvLxBmK%2BkrYQj%2FSiAVLNbqev6lJ%2F1ayWyl8hZOHoXmIze2KGldWyDZZ2rfOfibVM%2FRYIhZkyivQ2L8V%2Bi2rbKWtKihzV%2Bjd6unDBXwqinVT7kgOWoEpPP5gzjqNNxr1Tk7tfEeeI%3D"}],"group":"cf-nel","max_age":604800} nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800} server: cloudflare cf-ray: 6a3f1e314a4f3610-LAX alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400 HTTP/2 206 date: Mon, 25 Oct 2021 23:10:23 GMT content-type: video/mp4 content-length: 2 x-amz-id-2: J66qJEh5ZFf0gYNYJToPmSPj8v+uLTO3Esb6MRT9NKvPnir/hsrGRieewKPTVlQ+Ll7Bihl/c5Y= x-amz-request-id: 6EYHMMJV2C0JWC0J last-modified: Fri, 01 May 2020 15:20:57 GMT etag: "68360a312337530961dd70c330199fda-40" content-range: bytes 0-1/673223862 cache-control: max-age=31536000 cf-cache-status: MISS expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=anXPlg4qkx%2FhEGnZs8fxWkwqLtETuYlkWwG%2FeSajCwwrYBE%2BP3RCPJAU%2F3zlKOXpAkCm7fFCarlTBsZhdljrmUo5qn4%2Fji6YMChkp8qzcB588sQ1pP6p4NORMLar88l%2FO1xqzY3NAAY%3D"}],"group":"cf-nel","max_age":604800} nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800} server: cloudflare cf-ray: 6a3f1e350dae0575-LAX alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400 So the server is likely freaking out the media engine by responding to _some_ range requests with full files. (In reply to Jer Noble from comment #6) > One of the requirements for media playback on iOS and macOS is that the > server responds to requests with a valid Range: header with a 206 response > and a well formed Content-Range: response header. And this URL will give > out a 200 response for a Range request... sometimes. That indeed is an issue (related to Cloudflare) that I'm going to investigate, but I can replicate the same stuttering noted in the replication steps if I use the non-CDN URL: curl -I -r 0-1 https://s3.amazonaws.com/files.panomoments.com/bbb_sunflower_2160p_60fps_normal.mp4 This URL seems to provide 100% stable 206 responses. Are you able to replicate the stuttering using that URL? Actually, we may want to create a new bug ticket that is more focused on this new/worse behavior than this ticket was originally created for. Try going to this URL on Safari 15 (Desktop, iPadOS, iOS, etc.) - https://s3.amazonaws.com/data.panomoments.com/processed/5849a51bc26d08000b62f9f8/58a5dbc8cd5f48000bdbbe1f/uhd_dashinit.mp4 curl -I -r 0-1 https://s3.amazonaws.com/data.panomoments.com/processed/5849a51bc26d08000b62f9f8/58a5dbc8cd5f48000bdbbe1f/uhd_dashinit.mp4 Returns 100% valid 206 responses, but something about the GOP (being dense in I-Frames / 100% I-Frames) causes Safari playback to fail (or take a very very long time to start). Are you able to replicate? If so, should we reopen or create a new ticket? The above behavior is potentially more accurately described by this older bug (which has gotten worse in recent Safari versions) - https://bugs.webkit.org/show_bug.cgi?id=211295 |