Bug 229413 – iOS / iPadOS 15 video playback performance regression after seek

• Status: RESOLVED
• Resolution: MOVED
• Component: Media

[Dustin Kerstein]

In the latest iPadOS 15 Beta 6, when performing a manual seek while playing a video in Safari, the video will often stutter for several seconds before playing back normally. This behavior is not seen on iPadOS 14.x

1. Try playing this video in Safari on iPadOS 15 - https://files.panomoments.com/bbb_sunflower_2160p_60fps_normal.mp4
2. Let it play for ~60 seconds - note correct playback
3. Manually seek to ~20 mark - note playback will stutter for several seconds before it starts to play correctly
4. If unable to replicate on first try, seek to several different points in the timeline (within the cached buffer)

Please let me know if I can help with any further debug / testing.

[Dustin Kerstein]

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?

[Radar WebKit Bug Importer]

<rdar://problem/82281799>

[Sam Sneddon [:gsnedders]]

(and closing this because per your investigation this isn't actually a WebKit bug)

[Dustin Kerstein]

FYI, here are the related feedback assistant bugs.

FB9688897
FB9666426
FB9554184

Some of these issues may be more in VideoToolbox than in WebKit.

[Dustin Kerstein]

And a post on the Apple Developer Forums - https://developer.apple.com/forums/thread/693002

[Jer Noble]

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.

[Dustin Kerstein]

(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?

[Dustin Kerstein]

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?

[Dustin Kerstein]

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