[Webkit-unassigned] [Bug 193449] New: Multiple playing videos pool needs to be managed by browser

[bugzilla-daemon at webkit.org]

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

            Bug ID: 193449
           Summary: Multiple playing videos pool needs to be managed by
                    browser
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: iPhone / iPad
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media Elements
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ali.ghassemi at gmail.com

1- iOS by design can only play <x> concurrent videos as decoding is done on hardware. <x> depends on the device, for iPhone 6, it is 32.
2- If a video is "paused" it still occupies the hardware decoder and is considered part of the <x> concurrent videos limit.
3- This is all fine but default behaviour of the API is not. Essentially on <x>+1 video play, the call to `play()` method fails. It should instead evict one of the existing videos and play the x+1 instead of failing on the last one. The heuristics for evict could be FIFO based or something else, does not really matter.
4- The reason the current way the API works is bad, is that it pushes all the pool management back to the app developer and given this is iOS only and high-level, it is super easy to miss the need for this and it is a pain to code a state management here given the webpage may not even have access to all the playing videos to evict them ( they could be in an iframe).

To see this in action, visit: https://s.codepen.io/aghassemi/debug/VqgzjV on a real device (not sure what the # of hardware decoders of iPhone > 6 is but try with 6 if you can).
As you scroll this page, when a video comes into view, it plays, as it exists the view it gets paused. Notice that video #33 does not play because 32 other videos have been paused.

Thanks!
-Ali

-- 
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/20190115/2f8f8d14/attachment.html>