[Webkit-unassigned] [Bug 211295] New: Video buffering and degraded playback performance

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=211295

            Bug ID: 211295
           Summary: Video buffering and degraded playback performance
           Product: WebKit
           Version: Safari 13
          Hardware: All
                OS: All
            Status: NEW
          Severity: Major
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: dustin.kerstein at gmail.com

Below are two examples (with 4 variations total - directly loading via video.src and Blob as src) that show degraded playback in Safari (tested on 2019 Macbook Pro and iPad Pro 1st Gen). Both examples, across all 4 variations, playback with no issues in Firefox and Chrome. The issue appears to be related to the network requests being made in an attempt to buffer. Note that with the Fetch() variations it may take a little while to download the example videos.

Example #1
- 4k60fps with 100% I-Frames (and only 243 frames total).
- Try setting src directly and not using fetch() and note they behave the same way (which is different from Example #2)
- This broken playback can even be replicated by directly going to https://files.panomoments.com/uhd60fps.mp4 in the browser

var src = "https://files.panomoments.com/uhd60fps.mp4"
var video = document.createElement("VIDEO");
document.body.appendChild(video);
video.preload = 'none';
video.autoplay = true;
video.muted = true;
video.loop = true;
//video.src = src;  // Only use this when Fetch() is disabled.
fetch(src).then(function(response) {
  response.blob().then(function(myBlob) {
    video.src = window.URL.createObjectURL(myBlob);
  });
});


Example #2 
- 4k60fps with normal I-Frame / GOP encoding. Source - http://bbb3d.renderfarming.net/download.html
- Note that in this example, playback is better than the example above with 100% I-Frames. Only when using Blob as src does it slow down. When using Blob as src, each buffering requests' Resource Size is near the full size of the file. When not using Blob as src, each request is much smaller.

var src = "https://files.panomoments.com/bbb_sunflower_2160p_60fps_normal.mp4"
var video = document.createElement("VIDEO");
document.body.appendChild(video);
video.preload = 'none';
video.autoplay = true;
video.muted = true;
video.loop = true;
// video.src = src; // Only use this when Fetch() is disabled.
fetch(src).then(function(response) {
  response.blob().then(function(myBlob) {
    video.src = window.URL.createObjectURL(myBlob);
  });
});


Feel free to play around with a live version here - https://jsfiddle.net/dustinkerstein/5cmdy3p9/

To me it seems like there could be two possibly related issues - both potentially having to do with the buffering strategy. The first having more to do with videos that have many I-Frames (Example #1) and second, loading videos using Blob as src (more clearly evident in Example #2). Please let me know if I can get any further info / debug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200501/7b28d27d/attachment.htm>