@kainino0x Thanks for raising this. One case I'd like to mention is the subrect copy(and copy several video onto the same texture). Without the HTMLVideoElement + CopyExternalImageToTexture, it will need to import to get the GPUExternalTexture first and did the follow-up copies. From impl view, it will in-out dawn several times with a potential copy overhead(e.g. fallback path for the import), sync issues.
And it might be hard to define ImageSource if we miss the HTMLVideoElement :-)

Is there a specific use case for copying multiple videos into one texture? Especially since a lot of video sources have unpredictable resolutions, which makes them harder to fit into an array or atlas.

One example I can think of is loading all frames of a specific known video file into a texture (an atlas or array texture), e.g. for an animated or animatable texture on a 3D object. I'm not sure how common it would be to encode such textures as video files, though.

Of course, this could still be done with GPUExternalTextures, but the app would have to write their own code to draw the video frame into the target texture using a render pass.

One case is a camera matrix(a lots of camera) which used to generate immersive scene. They will have different view of the scene and a single resource to store camera contents and possible depth contents based on the protocol(or some rules). The following up algorithms could use these infos to generate a living 3d video and "walking" in the scene.
More details here. You can find that the stiching video frame is from lots of camera.

The base change has been landed, and this one is rebased and ready for discussion.

Previews, as seen when this build job started (a4aaf1e):
WebGPU | IDL
WGSL
Explainer

Resolution:

• Omit copyExternalImageToTexture for HTMLVideoElement for now.
• Open to adding it later
• See what developer feedback is