On Thu, Feb 1, 2024 at 5:18 PM Guido Urdaneta <[email protected]> wrote:
> To clarify about TAG reviews, there is no written policy prohibiting TAG > reviews. The policy (or rather the recommended practice) in a case like > this is to wait until there is consensus in the WG (i.e., the proposed > changes have landed in the official spec) before requesting the TAG review. > I see. To be clear, this is against the recommended practice for Chromium developers, which is to file for early TAG review as soon as code is landed behind a flag <https://www.chromium.org/blink/launching-features/#dev-trials:~:text=Once%20you%20have%20a%20functional%20and%20reasonably%20complete%20feature%20implementation%20available%20as%20a%20runtime%20enabled%20feature%2C%20we%20recommend%20(but%20don%27t%20require)%20that%20you%20request%20an%20Early%20Design%20Review%20from%20the%20TAG> . But as noted, that's only a recommendation, and not a requirement, so as long as you file for TAG review at least 1 month before the Intent to Ship <https://www.chromium.org/blink/launching-features/#dev-trials:~:text=You%20should%20submit%20this%20at%20least%20a%20month%20ahead%20of%20sending%20an%20Intent%20to%20Ship%2C%20to%20give%20the%20TAG%20sufficient%20time%20for%20meaningful%20feedback.>, that shouldn't be a problem. > > BTW, can you send the LGTM again? I forgot to cc blink-dev in my initial > reply and the LGTM was sent only to my email address. > LGTM! > On Thu, Feb 1, 2024 at 8:14 AM Domenic Denicola <[email protected]> > wrote: > >> Thanks for updating the explainer! >> >> I'm uneasy about this working group policy prohibiting TAG reviews. Can >> you link to where this policy is stated? If it's indeed not possible for >> WebRTC WG members to request TAG review due to Working Group restrictions, >> then that's probably something the API Owners need to discuss more broadly, >> and consider for the list of acceptable exceptions >> <https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/> >> . >> >> Nevertheless, given that the design here has changed significantly over >> the course of the Origin Trial, I think it's reasonable to delay TAG review >> until there's been more developer and community feedback on the new API. >> Just be aware that this could be a blocker when it comes time for Intent to >> Ship, and please file for review early enough that we can get a reply >> before then! >> >> So, LGTM to extend. >> >> On Mon, Jan 29, 2024 at 5:40 PM Guido Urdaneta <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Jan 29, 2024 at 8:35 AM Domenic Denicola <[email protected]> >>> wrote: >>> >>>> It's exciting to see the Origin Trial system working as intended, >>>> giving us time to get in-the-field feedback but also stay responsive to >>>> ongoing standards discussions about changing the shape of the API. >>>> >>>> Recalling the requirements for extending an origin trial >>>> <https://www.chromium.org/blink/launching-features/#origin-trials>, we >>>> need to see substantial progress demonstrated in all of the following >>>> areas: draft spec, TAG review, signals requests, outreach for feedback from >>>> the spec community, and WPT tests. I think these have mostly been met, with >>>> the exception of TAG review. Do you think it'd be reasonable to start the >>>> TAG review on the constructor proposal now, or do you think there's still a >>>> significant chance it might change due to WG feedback, such that we're >>>> better of continuing to delay the review? >>>> >>>> I think it's too early for a TAG review because the proposal hasn't >>> landed in the spec yet and the WebRTC WG policy nowadays is to wait for >>> specs to be complete before requesting a TAG review. >>> >>> >>> >>>> Also, a question on the explainer below. >>>> >>>> On Fri, Jan 26, 2024 at 8:27 PM Guido Urdaneta <[email protected]> >>>> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected], [email protected] >>>>> >>>>> >>>>> Explainer >>>>> >>>>> >>>>> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md >>>>> >>>> >>>> Is this explainer up to date with the newest specification proposal? The >>>> specification PR you link below introduces RTCEncodedVideoFrame >>>> and RTCEncodedAudioFrame constructors, but the explainer doesn't seem to >>>> reference either of those. >>>> >>> It is updated now :) >>> For simplicity, the explainer uses only the RTCEncodedVideoFrame >>> constructor. >>> >>> >>>> Additionally, the explainer seems to talk about a clone "operator" (is >>>> that a way of saying method?), but I don't see that in the spec PR. >>>> >>>> >>> That part is now removed because a clone operation is already part of >>> the spec via structuredClone() and is no longer part of this proposal. >>> >>> >>> >>>> >>>>> Specification >>>>> >>>>> https://github.com/w3c/webrtc-encoded-transform/pull/223/files >>>>> >>>>> Original I2E >>>>> >>>>> >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/yqwA-jXv6VY/m/fCkBkclxAAAJ >>>>> >>>>> >>>>> >>>>> Summary >>>>> >>>>> Add a feature to the WebRTC Encoded Transform API that allows >>>>> manipulating audio and video frame metadata. >>>>> >>>>> Background: A number of use cases have been identified that require >>>>> the manipulation of the metadata of WebRTC encoded frames without decoding >>>>> them first. >>>>> >>>>> These include: >>>>> >>>>> - Receiving data in encoded form and forwarding it. >>>>> >>>>> - Sending data that has been encoded previously >>>>> >>>>> - Sending data that has been received in encoded form >>>>> >>>>> In particular, we want to support the use case of glitch-free >>>>> forwarding of media coming from multiple redundant peer connections that >>>>> provide the same media payloads but with different metadata. >>>>> >>>>> Issue links: <https://github.com/w3c/webrtc-nv-use-cases/issues/77> >>>>> >>>>> https://github.com/w3c/webrtc-nv-use-cases/issues/77 >>>>> >>>>> https://github.com/w3c/webrtc-nv-use-cases/issues/122 >>>>> >>>>> https://github.com/w3c/webrtc-encoded-transform/issues/211 >>>>> >>>>> >>>>> >>>>> Blink component >>>>> >>>>> Blink>WebRTC >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC> >>>>> >>>>> >>>>> TAG review >>>>> >>>>> The original full spec was reviewed by TAG here: >>>>> https://github.com/w3ctag/design-reviews/issues/531 >>>>> >>>>> No TAG review has been requested for this incremental change, since it >>>>> is a small addition and its API surface might change as a result of >>>>> feedback from the origin trial and ongoing discussions in the WebRTC >>>>> working group. >>>>> >>>>> >>>>> TAG review status >>>>> >>>>> Issues addressed for the original spec. Not yet requested for the >>>>> incremental change. >>>>> >>>>> >>>>> Chromium Trial Name >>>>> >>>>> RTCEncodedFrameSetMetadata >>>>> >>>>> >>>>> WebFeature UseCounter name >>>>> >>>>> V8RTCEncodedVideoFrame_SetMetadata_Method >>>>> >>>>> >>>>> Link to origin trial feedback summary >>>>> >>>>> >>>>> https://docs.google.com/document/d/1oCgXj0bEhJS6WeJ0T-gV5AVhSaEeVixssqm02m4eU9Q/r/0-f4cSv_CIFwIpVPcIKb89TQ/edit?tab=t.0 >>>>> >>>>> >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> Interoperability risk: There is the risk that other browsers will not >>>>> implement this feature. We are mitigating this risk by pursuing consensus >>>>> in the W3C WebRTC Working Group so that it becomes part of the WebRTC >>>>> encoded transform spec supported by all browsers. >>>>> >>>>> >>>>> Compatibility risk: This is a new feature intended to support a new >>>>> use case. It introduces no breaking changes, so we do not expect any >>>>> compatibility issues. >>>>> >>>>> >>>>> Gecko: No signal requested yet. Positive initial feedback during WG >>>>> discussions. >>>>> >>>>> >>>>> WebKit: No signal requested yet. Positive initial feedback during WG >>>>> discussions. >>>>> >>>>> >>>>> Web developers: Positive >>>>> >>>>> >>>>> Other signals: >>>>> >>>>> >>>>> Ergonomics >>>>> >>>>> This feature is an extension to WebRTC Encoded Transform, which itself >>>>> is an extension to WebRTC/RTCPeerConnection. >>>>> >>>>> >>>>> Activation >>>>> >>>>> N/A >>>>> >>>>> >>>>> Security >>>>> >>>>> No new security risks identified. >>>>> >>>>> >>>>> WebView application risks >>>>> >>>>> None >>>>> >>>>> >>>>> >>>>> Reason this experiment is being extended >>>>> >>>>> We have received positive developer feedback and have validated that >>>>> the proposal supports the intended use case, but the API requires some >>>>> changes in order to achieve consensus in the W3C WebRTC Working Group. >>>>> This >>>>> is the current status: >>>>> >>>>> 1. There is consensus to support the use case, which is already part >>>>> of the official "WebRTC Extended Use Cases" document from the WG. See >>>>> requirement N39 in https://www.w3.org/TR/webrtc-nv-use-cases/#auction >>>>> >>>>> 2. There is consensus to develop a spec proposal that includes changes >>>>> to the API surface subject to this origin trial. More specifically, the >>>>> initial consensus is to remove the setMetadata method in frames (as >>>>> originally proposed) and instead introduce a constructor for creating new >>>>> frames given an existing frame and new metadata, following a pattern >>>>> already established by WebCodecs. In addition, the WG agreed to the >>>>> introduction of a class that allows attaching a source of encoded frames >>>>> to >>>>> the sender of an RTCRtpPeerConnection. See >>>>> https://github.com/w3c/webrtc-encoded-transform/issues/211#issuecomment-1853419603 >>>>> and https://www.w3.org/2023/12/12-webrtc-minutes.html#t06. From the >>>>> WG's point of view, both changes are seen as parts of the same package >>>>> (i.e., they will be looked at together, not separately). >>>>> >>>>> >>>>> In this Intent to Extend Experiment, we are requesting to extend the >>>>> origin trial for 3 milestones (124 to 126 inclusive). During this period >>>>> we'll introduce the updated frame API (i.e., the constructor) and will >>>>> temporarily keep the setMetadata method to allow developers to migrate to >>>>> the new API. The encoded frame source will be pursued by a separate >>>>> intent. >>>>> >>>>> >>>>> Ongoing technical constraints >>>>> >>>>> None. >>>>> >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> N/A >>>>> >>>>> >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>> >>>>> Yes >>>>> >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> Currently tested using unit and Web tests. Web tests will be moved to >>>>> WPT once the final API shape is accepted by the WebRTC WG. >>>>> >>>>> >>>>> Flag name on chrome://flags >>>>> >>>>> None >>>>> >>>>> >>>>> Finch feature name >>>>> >>>>> RTCEncodedFrameSetMetadata >>>>> >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> False >>>>> >>>>> >>>>> Tracking bug >>>>> >>>>> https://crbug.com/1393964 >>>>> >>>>> >>>>> Estimated milestones >>>>> >>>>> OriginTrial desktop last >>>>> >>>>> 126 >>>>> >>>>> OriginTrial desktop first >>>>> >>>>> 118 >>>>> >>>>> >>>>> OriginTrial Android last >>>>> >>>>> 126 >>>>> >>>>> OriginTrial Android first >>>>> >>>>> 118 >>>>> >>>>> >>>>> OriginTrial webView last >>>>> >>>>> 126 >>>>> >>>>> OriginTrial webView first >>>>> >>>>> 118 >>>>> >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5116073827893248 >>>>> >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> Intent to prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/x2ZACgXrqp0 >>>>> >>>>> Intent to experiment: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/yqwA-jXv6VY/m/fCkBkclxAAAJ >>>>> >>>>> >>>>> >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BBuZxY7yNLBte5CVtk_%3DZfwpZnTn%3DWPCWbt%3DGCn4wWXCr2wtQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BBuZxY7yNLBte5CVtk_%3DZfwpZnTn%3DWPCWbt%3DGCn4wWXCr2wtQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BBuZxbE1-3Zd%2BDSJ-r%2BMKBCwZ%2Bw0tXDA-BgUC-do%2BA4j5YyRg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BBuZxbE1-3Zd%2BDSJ-r%2BMKBCwZ%2Bw0tXDA-BgUC-do%2BA4j5YyRg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-JcyYB-jgKXjnF3J136VKgfuhzMaJLU4%2BFafX0qpGr0w%40mail.gmail.com.
