It's possible for MediaPlayerPrivateAVFoundationObjC::waitForVideoOutputMediaDataWillChange to be called re-entrantly, if the RunLoop::run() call ends up processing an event that also wants to synchronously update the media image. This can cause a hang:
1. Enter the outer waitForVideoOutputMediaDataWillChange() call.
2. Set up the outer timeout timer.
3. Call RunLoop::run().
3.1. Enter the inner waitForVideoOutputMediaDataWillChange() call.
3.2. Set up the inner timeout timer.
3.3. Call RunLoop::run().
3.3.1. Wait for new RunLoop events, and none arrive.
3.3.2. The outer timeout timer fires, calling RunLoop::stop().
3.4. Return from waitForVideoOutputMediaDataWillChange(), cancelling the inner timeout timer.
3.5. Wait for more events on the run loop, forever.
I encountered this with my bug 232565 patch applied running webgl/1.0.x/conformance/textures/misc/texture-corner-case-videos.html.
(In reply to Cameron McCormack (:heycam) from comment #0)
> I encountered this with my bug 232565 patch applied running
bug 230766 rather
Created attachment 443274 [details]
Tools/Scripts/svn-apply failed to apply attachment 443274 [details] to trunk.
Please resolve the conflicts and upload a new patch.
Created attachment 443353 [details]
Patch for landing
The patch conflicted with bug 232676, which made me realize it was wrong to be modifying m_waitForVideoOutputMediaDataWillChangeTimedOut inside the RunLoop::main() task, since in WebKitLegacy that's the UI thread, and the MediaPlayerPrivateAVFoundationObjC object is created on the web thread. So I've tweaked it to avoid that.
Committed r285330 (243895@main): <https://commits.webkit.org/243895@main>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 443353 [details].