Bug 279891 – Green flickering when rendering VideoFrame to canvas using WebGL

• Status: NEW
• Component: WebGL

[Michael Hagar]

Created attachment 472590 [details]
Demo code that can reproduce the issue on Safari 18 on Intel platform

On Safari 18 on Intel (not on M1), rendering VideoFrames to a canvas using WebGL will show green flickering. See the attachment for demo code that reproduces the issue (Click "opencamera", then "startDraw").

[Michael Hagar]

For simpler testing, here is a deployed version of the demo: https://disco-yielding-chance.glitch.me/

[Alexey Proskuryakov]

Thank you for the report!

Could you please clarify if this is a new issue in Safari 18, and Safari 17.x definitely works as expected?

[Michael Hagar]

I haven't tested it myself, but another developer reported it occurs on Safari 17.5 as well. So I don't think it's a new issue.

[Radar WebKit Bug Importer]

<rdar://problem/136672215>

[Kimmo Kinnunen]

Thank you for the report!

I can see some flashing on Intel. It's not yet clear to me if it's a test-case issue or implementation issue. The test case seems to create green textures.

It would be helpful if you would simplify the test-case. With a quick glance, I have hard time understanding where the video frame is being draw to webgl -- in main context or in worker.
If only possible, please remove:
 - any extra unnecessary files
 - any unneccessary variables, functions and codepaths: use_sub/use_draw, 2d context related code, etc.
 - any extra unneccessary communication between workers
 - if workers are not needed to reproduce the issue, please remove them, too

This would very much help me to address the issue.

[Michael Hagar]

Created attachment 472740 [details]
Demo code that can reproduce the issue on Safari 18 on Intel Platform

Updated the code to remove unnecessary code.

[Michael Hagar]

Sure, I just attached a new version of the test code that removes the unnecessary code. In our case, using a Worker is required because we're relying on MediaStreamTrackProcessor, which is only available from a worker. For clarification, the VideoFrame is drawn to WebGL in a worker.

[Michael Hagar]

Looking into it more, it seems like the issue only happens if we close the VideoFrame via VideoFrame.close(). If I remove that call, or instead only close the previous frame, it works. 

Is it possible that the VideoFrame is being closed before the call to `texImage2d` has finished internally?

[Kimmo Kinnunen]

> Is it possible that the VideoFrame is being closed before the call to `texImage2d` has finished internally?

Thanks for the analysis, it is plausible though we should have a mechanism to handle this. It's unclear if it's broken, for example due to workers.