Bug 280207 – Scrubbing VP9 video causes video element to fail with HTTP range

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Media

[Ian S]

Using the latest nightly build (284094@main) on macOS 15, loading a video and scrubbing it causes the video element to fail and display "Error". This error is reproducible on release Safari, technology preview, and nightly, as well as Safari on iOS 18 (hence why I believe this is a WebKit bug).

The video will load and play normally, but as soon as you try to scrub forward in the video it will fail. The only message printed to the console is "Failed to load resource: Plug-in handled load".

This issue only happens on servers that support HTTP range requests. If no range support of presented by the server, the video can be scrubbed (mostly) without issue (I say mostly because there's weird artifacts, but that's a different issue for another time).

The video is being served from nginx. Video details from ffprobe:

```
Input #0, matroska,webm, from 'VDkhN-e42A8.webm':
  Metadata:
    ENCODER         : Lavf61.1.100
  Duration: 00:32:50.39, start: 0.000000, bitrate: 8235 kb/s
  Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 2560x1440, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn (default)
      Metadata:
        DURATION        : 00:32:50.349000000
  Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
      Metadata:
        DURATION        : 00:32:50.388000000
```

The browser makes a request for the video file and will download the entire file (Request #1), but scrubbing the video beyond where the player has buffered triggered 4 more requests each for different amounts of data. The last 3 of them show as failed, though there's no information as to what went wrong beyond devtools just saying an error occured.

Request #1:

> GET /VDkhN-e42A8.webm
> Accept: */*
> Sec-Fetch-Dest: video
> Sec-Fetch-Mode: no-cors
> Sec-Fetch-Site: same-origin
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Safari/605.1.15
< 200 
< Content-Type: video/webm
< Last-Modified: Fri, 13 Sep 2024 04:34:27 GMT
< X-XSS-Protection: 1; mode=block
< Referrer-Policy: no-referrer
< Date: Mon, 23 Sep 2024 20:43:38 GMT
< Content-Length: 2028292448
< X-Content-Type-Options: nosniff
< Accept-Ranges: bytes
< ETag: "66e3c0d3-78e54960"
< X-Frame-Options: SAMEORIGIN
< Server: nginx/1.27.0
< Strict-Transport-Security: max-age=63072000

Request #2:

> :method: GET
> :scheme: https
> :authority: [redacted]
> :path: /VDkhN-e42A8.webm
> Accept: */*
> Sec-Fetch-Site: same-origin
> Sec-Fetch-Dest: video
> Range: bytes=0-1
> Sec-Fetch-Mode: no-cors
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Safari/605.1.15
> Accept-Language: en-CA,en-US;q=0.9,en;q=0.8
> Accept-Encoding: identity
> X-Playback-Session-Id: 9A133EA9-D7E0-4659-9D04-D0A922DAF37D
> Priority: u=3, i
< :status: 206
< Content-Type: video/webm
< Last-Modified: Fri, 13 Sep 2024 04:34:27 GMT
< X-XSS-Protection: 1; mode=block
< Referrer-Policy: no-referrer
< Date: Mon, 23 Sep 2024 20:43:52 GMT
< Content-Length: 2
< X-Content-Type-Options: nosniff
< ETag: "66e3c0d3-78e54960"
< Content-Range: bytes 0-1/2028292448
< X-Frame-Options: SAMEORIGIN
< Server: nginx/1.27.0
< Strict-Transport-Security: max-age=63072000

Request #3:

> GET /VDkhN-e42A8.webm
> Range: bytes=0-2028292447
> Accept: */*
> Connection: Keep-Alive
> Accept-Encoding: identity
> Sec-Fetch-Dest: video
> Sec-Fetch-Mode: no-cors
> Sec-Fetch-Site: same-origin
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Safari/605.1.15
> X-Playback-Session-Id: 9A133EA9-D7E0-4659-9D04-D0A922DAF37D
< 206 
< Content-Type: video/webm
< Last-Modified: Fri, 13 Sep 2024 04:34:27 GMT
< X-XSS-Protection: 1; mode=block
< Referrer-Policy: no-referrer
< Date: Mon, 23 Sep 2024 20:43:52 GMT
< Content-Length: 2028292448
< X-Content-Type-Options: nosniff
< ETag: "66e3c0d3-78e54960"
< Content-Range: bytes 0-2028292447/2028292448
< X-Frame-Options: SAMEORIGIN
< Server: nginx/1.27.0
< Strict-Transport-Security: max-age=63072000

Request #4:

> GET /VDkhN-e42A8.webm
> Range: bytes=440729600-2028292447
> Accept: */*
> Connection: Keep-Alive
> Accept-Encoding: identity
> Sec-Fetch-Dest: video
> Sec-Fetch-Mode: no-cors
> Sec-Fetch-Site: same-origin
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Safari/605.1.15
> X-Playback-Session-Id: 9A133EA9-D7E0-4659-9D04-D0A922DAF37D
< 206 
< Content-Type: video/webm
< Last-Modified: Fri, 13 Sep 2024 04:34:27 GMT
< X-XSS-Protection: 1; mode=block
< Referrer-Policy: no-referrer
< Date: Mon, 23 Sep 2024 20:43:52 GMT
< Content-Length: 1587562848
< X-Content-Type-Options: nosniff
< ETag: "66e3c0d3-78e54960"
< Content-Range: bytes 440729600-2028292447/2028292448
< X-Frame-Options: SAMEORIGIN
< Server: nginx/1.27.0
< Strict-Transport-Security: max-age=63072000

Request #5:

> GET /VDkhN-e42A8.webm
> Range: bytes=1595736064-2028292447
> Accept: */*
> Connection: Keep-Alive
> Accept-Encoding: identity
> Sec-Fetch-Dest: video
> Sec-Fetch-Mode: no-cors
> Sec-Fetch-Site: same-origin
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Safari/605.1.15
> X-Playback-Session-Id: 9A133EA9-D7E0-4659-9D04-D0A922DAF37D
< 206 
< Content-Type: video/webm
< Last-Modified: Fri, 13 Sep 2024 04:34:27 GMT
< X-XSS-Protection: 1; mode=block
< Referrer-Policy: no-referrer
< Date: Mon, 23 Sep 2024 20:43:52 GMT
< Content-Length: 432556384
< X-Content-Type-Options: nosniff
< ETag: "66e3c0d3-78e54960"
< Content-Range: bytes 1595736064-2028292447/2028292448
< X-Frame-Options: SAMEORIGIN
< Server: nginx/1.27.0
< Strict-Transport-Security: max-age=63072000

[Alexey Proskuryakov]

Thank you for the report! Do you happen to have an example webpage where we could easily test this?

[Radar WebKit Bug Importer]

<rdar://problem/136996494>

[Jean-Yves Avenard [:jya]]

I can reproduce with https://jyavenard.github.io/htmltests/mediatest/webm/Morocco_1080p30.webm
and seeking in an unbuffered area.

However, there's no use of range-request by the webm player other than when playback starts and after reading the metadata.

We start reading, as soon as the metadata has been read we interrupt the connection. Then we will issue a single request to resume from where we left off to the end.

So at most, when playing a webm on Apple device, you will see two requests.

[Ian S]

I have uploaded a video file that can reproduce this issue:

https://box.ecn.io/NORWAY_TRIP.webm

Please note that I will eventually take this down so if possible let me know when you're finished with it.

Thank you!

[Jean-Yves Avenard [:jya]]

it's okay, I posted above a ling for which I can reproduce.

thank you for the report

[Jean-Yves Avenard [:jya]]

*** This bug has been marked as a duplicate of bug 272095 ***