Bug 173505 – [MSE] Seeking or entering fullscreen can cause extreme CPU usage

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jer Noble]

[MSE] Seeking or entering fullscreen can cause extreme CPU usage

[Jer Noble]

<rdar://problem/32623694>

[Jer Noble]

Created attachment 313175 [details]
Patch

[Tim Horton]

Comment on attachment 313175 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=313175&action=review

> Source/WebCore/ChangeLog:11
> +        performance regression in the normal playback path, where WebKit will effective 

effective append?

[Jer Noble]

Committed r218438: <http://trac.webkit.org/changeset/218438>

[WebKit Commit Bot]

Re-opened since this is blocked by bug 173515

[Jer Noble]

I found the underlying issue behind the test failures, and it has nothing to do with this patch, except in that this patch causes it to happen much more frequently.

When a client specifies a timestamp offset, the SourceBuffer code stores the current presentation time as a float (because a MediaTime + float = float).  But the sample itself store it as a MediaTime.  Generally speaking, we use the sample's presentation time as the key to our storage, but in one instance (the decodeQueue) we are using the local value of presentation time (the float). This leads to a mismatch later when it comes time to remove those samples from the decode queue, so the samples are left in the decode queue, which causes a decode error, which breaks this test.

(BTW, I'm pretty sure that this is the cause of some existing flakiness of some of these tests.)

[Jer Noble]

Created attachment 313224 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 313224 [details]
Patch for landing

Clearing flags on attachment: 313224

Committed r218463: <http://trac.webkit.org/changeset/218463>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.