search

w3c / mediacapture-transform

MediaStreamTrack Insertable Media Processing using Streams
https://w3c.github.io/mediacapture-transform/
Other
44 stars 20 forks source link

Update proposal according to WG directions #66

Closed alvestrand closed 2 years ago

alvestrand commented 3 years ago

This prepares the document for adoption as a WG document.

alvestrand commented 2 years ago

I'm interested in getting this to the WG ASAP for the call for adoption, so would be inclined to minimize changes. Question: In a couple of places, it's been suggested to "leave this in alvestrand/mediacapture-transform". This can't be done until the move/clone dance has completed, of course (this IS the alvestrand repo). But it makes sense after the move/clone dance has completed.

WDYT about augmenting the backwards compatibility section with an explicit pointer to "older version hosted at..."?

youennf commented 2 years ago

WDYT about augmenting the backwards compatibility section with an explicit pointer to "older version hosted at..."?

It seems ok for the standard draft to acknowledge the initial non standard document it was based upon, for instance as a link in the introduction. The non standard document can then document at will how to shim/feature detect/migrate from the non standard API to the standard API.

jan-ivar commented 2 years ago

Sorry for the late reply.

WebIDL is a clearer exposition format than prose, and this is an informative section.

I think the WebIDL should at least be enclosed in a <div class="example"> tag like we do in mediacapture, otherwise it gets picked up by various W3C tools that generate all sorts of tests meant for standards track APIs.

But if we link to the non standard document as Youenn suggests, then I'd prefer we move this WebIDL there.

I'll do a PR for examples.

jan-ivar commented 2 years ago

I'll do a PR for examples.

Added https://github.com/alvestrand/mediacapture-transform/pull/67

alvestrand commented 2 years ago

Sorry for the late reply.

WebIDL is a clearer exposition format than prose, and this is an informative section.

I think the WebIDL should at least be enclosed in a <div class="example"> tag like we do in mediacapture, otherwise it gets picked up by various W3C tools that generate all sorts of tests meant for standards track APIs.

Good point. I added the enclosing "example" div as a direct commit to main. With the merger of the examples, I'm sending the note to Bernard to ask him to send out the CfC on adoption.

We'll continue changing the document afterwards.

foolip commented 1 year ago

I came across this note in https://w3c.github.io/mediacapture-transform/#track-processor-interface:

There is WG consensus that the interface should be exposed on DedicatedWorker. There is no WG consensus on whether or not the interface should not be exposed on Window.

Trying to figure out what that's about I found my way here. But is there an issue or something tracking this issue? That issue in short is that Chrome exposes MediaStreamTrackProcessor only on Window and the spec only on DedicatedWorker.

dontcallmedom commented 1 year ago

23 is where this has been discussed