- From: nisse-work via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Jun 2022 12:06:41 +0000
- To: public-webrtc-logs@w3.org
Back to setMetadata. I can make a pull request to add that, but I need some guidance about how it should work. 1. Newbie question: The type `dictionary RTCEncodedVideoFrameMetadata` listen in the spec, is that a plain javascript dictionary to the application, so that, e.g., it could be constructed as `{"width" : 100}` ? It seems clear that this should be the argument type for setMetadata, for consistency with the getMetadata method. 2. Return value: The method needs a way to indicate success or failure (might fail, e.g, if application tries to set unknown keys, or invalid values such as width < 0). Should this simply be a bool (true for success), or something more complex? Or should it be an asynchronous operation with promise/callback? 3. Should caller be required to pass a dictionary with all defined attributes present (typical pattern would then be getMetadata, modify one or two attributes, setMetadata)? Or is it fine to pass a partially populated dictionary, and then leave all attributes not mentioned unchanged? 4. Most of the attributes seem rather inappropriate for the application to change. E.g., changing the spatial index or dependency list will likely break decoding at the remote end. Setting csrcs (the use case I have in mind) is the only one that looks reasonably safe. Maybe it's better to define a specific method to change cscrs only? I'm thinking of the case where a webrtc encoder is used; in case the application has it's own encoder (implemented in js or webasm), then the situation is different and the application has to know, and populate, all the attributes of the encoded frame. -- GitHub Notification of comment by nisse-work Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/135#issuecomment-1161659009 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 June 2022 12:06:43 UTC