- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Tue, 24 Oct 2023 15:27:40 +0000
- To: public-webrtc-logs@w3.org
Funny, I was just typing this into a document for internal discussion (wanted to get some feedback before proposing this in the WG): # Establishing a WebCodec-using sender and/or receiver When a sender (or receiver, but they’re similar enough that just the sender side is explained in detail here) is first established (through AddTransceiver, through ontrack, or through other means), the sender is in an unconfigured state; it leaves this state either by having its “transform” member set, or by starting to process RTP packets. There is a set of classes that implement the [RTCRtpScriptSink ](https://pr-preview.s3.amazonaws.com/w3c/webrtc-encoded-transform/pull/207.html#RTCRtpScriptTransformer-interfaces)interface (introduced in PR 207). For this version, we assume the same initialization steps as for RTCRtpTransformer. This mirrors the [RTCRtpScriptTransformer](https://www.w3.org/TR/webrtc-encoded-transform/#RTCRtpScriptTransformer-interfaces) interface, but has different semantics: When applied, the sender will not initialize its encoder component. It will expect all frames to come in via the RTCRtpScriptSink object’s “writable” stream. When applied, the sender will assume no responsibility for configuring upstream bandwidth or send signals upstream; it will make this information available through the RTCRtpScriptSink object interface only. A similar process, using the RTCRtpScriptSource interface, applies to the RTPReceiver. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/211#issuecomment-1777485835 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 24 October 2023 15:27:45 UTC