Add WebCodecs VideoFrame as CanvasImageSource.

[dalecurtis]

Adding VideoFrame as a CanvasImageSource allows drawImage(),
createImageBitmap(), and texImage() to interoperate with VideoFrames.
VideoFrames are effectively the same as the existing point-in-time
capture done for HTMLVideoElement on each of these interfaces.

This adds a non-normative reference on the WebCodecs spec for the
VideoFrame interface and associated properties to accomplish this.

Bug: w3c/webcodecs#158

• [ x ] At least two implementers are interested (and none opposed):
  • Firefox (spec co-editor): Web Codecs mozilla/standards-positions#209
  • Chrome: https://www.chromestatus.com/feature/5669293909868544
  • Edge (spec co-editor)
  • (Safari has not made an official position statement)
• [ x ] Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/blob/master/webcodecs/videoFrame-drawImage.any.js
  • https://github.com/web-platform-tests/wpt/blob/master/webcodecs/videoFrame-createImageBitmap.any.js
• [ 1/n ] Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1175907
  • Firefox: WebCodecs implementation not started.
  • Safari: No official position, so WebCodecs implementation not started.

---

/canvas.html ( diff )
/imagebitmap-and-animations.html ( diff )
/infrastructure.html ( diff )
/references.html ( diff )

[annevk]

Is this based on existing language? You cannot really resolve something without queuing a task if you're in parallel. It's also unclear why this needs to go in parallel.

[dalecurtis]

Just based on the existing language. All the others said this in some form, so I cloned it here.

[dalecurtis]

@annevk did you want any changes here? Since this is existing language it seems like a separate cleanup CL would be a better place for this?

[annevk]

It's okay.

[annevk]

By the way, does a VideoFrame object only ever contain same-origin information?

[dalecurtis]

By the way, does a VideoFrame object only ever contain same-origin information?

Yes, VideoFrames are required to be same origin.

[annevk]

cc @whatwg/canvas

[kenrussell]

cc @whatwg/canvas

Excited to see this being added to the spec! It'll be a more performant code path than drawing HTMLVideoElement to a canvas.

[fserb]

LGTM

[annevk]

I pushed some nits and thought this was ready to land, but https://w3c.github.io/webcodecs/#dom-videoframe-display-width-slot does not match the name in this PR (same for the other slot). This is also the first time I'm seeing slots with spaces in them.

[dalecurtis]

Whoops, fixed up the names, hopefully the spaces work out okay. If not @chcunningham in case that's a style issue.

[annevk]

I'll let @domenic make a call on that. @dalecurtis you need to join the googlers organization and make your membership public to satisfy the IPR bot.

[domenic]

I have no problem with spaces in internal slots. (Besides my eternal slight regret for introducing [[internal slots]] into the web spec ecosystem in the first place, heh.)

[dalecurtis]

@annevk the membership should be public now. Thanks!

[annevk]

@dalecurtis when I go to your profile I see google, but not googlers. Only the latter works for WHATWG IPR.

[dalecurtis]

Huh, TIL, that's confusing. I've figured out what that is and have joined accordingly.

[dalecurtis]

Thanks everyone!