- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Nov 2023 08:42:33 +0000
- To: public-webrtc-logs@w3.org
> This, together with something along the lines of @alvestrand's proposal for congestion control should be enough to satisfy all the requirements and address all the concerns presented so far, assuming we agree that a frame-level API That is a fair summary. > it should support RTCEncodedVideoFrames/RTCEncodedAudioFrames instead of or in addition to the WebCodec versions It might be ok as a convenience/shortcut for web developers. The internal algorithm should ideally process WebCodecs objects so that the API surface is based on WebCodecs. > enqueued on the RTCRtpSenderEncodedSource of the output PCs after invoking a `setMetadata()` method to adjust frame IDs to the output peer connection Why would we need to call `setMetadata()`? This API basically replaces the encoder which does not have the notion of a frameID. Shouldn't it be the backend that computes it? -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/211#issuecomment-1809761483 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 November 2023 08:42:35 UTC