You're right, I was cranking out spec PRs and totally forgot about that! Will mark as draft until that's added.

LGTM as well! (Minor added bonus to this approach I haven't seen anybody comment on: It could reduce BindGroup churn.)

As for notifying developers that the texture is still alive, seems like a promise would be appropriate?

function updateVideoTexture() {
  videoTexture = gpuDevice.importExternalTexture({ source: video });
  videoTexture.expired.then(updateVideoTexture);
}

As for notifying developers that the texture is still alive, seems like a promise would be appropriate?

This would be very similar to requestVideoFrameCallback (rVFC) but phrased as a promise instead. However since it's tied to the end of the frame lifetime instead of the beginning, it could lead to developers to re-importing the video when the previous frame expires rather than when they need it, which could result in <1 animation frame of latency when the video advances between the beginning and end of the animation frame, because video frame advancement is totally desynchronized with the animation loop AFAIU. E.g. with both video and animation updating at the same rate, say 60Hz:

externalTexture.expired.then where expiry happens AFTER rAF callbacks:

• Video element advances to frame 2
• rAF callback, app renders frame 1 <- outdated render
• Expire imported frame 1
• Page renders
• expired.then callback imports frame 2 <- doesn't run until now because "update the rendering" was running
• Video element advances to frame 3
• rAF callback renders frame 2 <- outdated render

rVFC:

• Video element advances to frame 2
• rVFC callback imports frame 2
• rAF callback renders frame 2 <- up-to-date render
• Expire imported frame 1
• Page renders
• Video element advances to frame 3
• rVFC callback imports frame 3
• rAF callback renders frame 3 <- up-to-date render

That said, working through this exercise made me realize that a synchronous isExpired that changes after rAF callbacks is even worse:

externalTexture.isExpired where it changes AFTER rAF callbacks:

• Video element advances to frame 2
• rAF callback, app checks if frame 1 is still valid; it is, so it renders frame 1 <- outdated render
• Expire imported frame 1
• Page renders
• Video element advances to frame 3
• rAF callback, app checks if frame 1 is still valid; it isn't, so imports and renders frame 3 <- up-to-date render
• Expire imported frame 2
• Page renders
• Video element advances to frame 4
• rAF callback, app checks if frame 3 is still valid; it is, so it renders frame 3 <- outdated render

In conclusion, I need to think about this some more.

TIL requestVideoFrameCallback callbacks (as drafted) are called in "update the rendering" immediately before rAF callbacks.

Note: The effective rate at which callbacks are run is the lesser rate between the video’s rate and the browser’s rate. When the video rate is lower than the browser rate, the callbacks' rate is limited by the frequency at which new frames are presented. When the video rate is greater than the browser rate, the callbacks' rate is limited by the frequency of the update the rendering steps. This means, a 25fps video playing in a browser that paints at 60Hz would fire callbacks at 25Hz; a 120fps video in that same 60Hz browser would fire callbacks at 60Hz.

https://wicg.github.io/video-rvfc/#video-rvfc-procedures

Imitating the lifetimes in rVFC would fix it:

externalTexture.isExpired where it changes BEFORE rAF (before or after rVFC?):

• Video element advances to frame 2
• Expire imported frame 1
• rAF callback, app checks if frame 1 is still valid; it isn't, so imports and renders frame 2 <- up-to-date render
• Page renders
• Video element advances to frame 3
• Expire imported frame 2
• rAF callback, app checks if frame 2 is still valid; it isn't, so imports and renders frame 3 <- up-to-date render
• Page renders

Though we might still want to guarantee that an imported frame lasts at least until the next end-of-rAF in case it was imported in some other async code. (This doesn't affect this case study.)

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

Updated description with latest changes.

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

Just to make sure I completely understand #2302 (comment), see is what would happen? (it sounds good)

• Video element advances to frame 2
• Update the rendering
  • Expire imported frame 1
  • rAF callback, app checks if frame 1 is still valid; it isn't, so imports and renders frame 2 <- up-to-date render
  • Page renders
• Video element advances to frame 3
• Update the rendering
  • Expire imported frame 2
  • rAF callback, app checks if frame 2 is still valid; it isn't, so imports and renders frame 3 <- up-to-date render
  • Page renders

Yup that looks correct.

Technically the video element can advance at any time (I think). I tried to diagram this out yesterday but the resulting diagram was kind of incomprehensible. The rules as written in the spec make more sense. (Just before rVFC/rAF, textures expire if they're now outdated.)

Editors to decide exactly what input we need from the group, or specific individuals.

I'm putting this on the tacit resolution queue for next meeting (although I'll be OOO). Here's a summary for the meeting:

The current spec says imported video textures are closed very quickly (in a microtask after the current task). This leads to developers needing to reimport frequently, which makes them feel they should copy out the data instead of reimporting. Additionally, browsers may need a cache for reimport performance.

This PR extends the lifetime until the frame is not current on the source video anymore. For predictability, expiry always happens at a very specific point - within a frame after the video advances, the lifetime ends immediately before requestVideoFrameCallback callbacks, which are just before requestAnimationFrame callbacks.

It also adds a boolean attribute GPUExternalTexture.expired which tells the app to reimport to get a new frame. Apps use this if WebGPU rendering isn't driven by requestVideoFrameCallback already. (Could be approximated by observing requestVideoFrameCallback, but that's a bit indirect, slightly imprecise, and not in all browsers. This is direct and easy to use.)

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

Removing 'needs-cts-issue' for now because this is obsolete and will be updated in a future pull request to fix #3324.