- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Sep 2023 15:54:46 +0000
- To: public-webrtc-logs@w3.org
@alvestrand, @aboba, I was initially thinking we could add an API for the web page to expose the target bitrate overhead of the transform. Rethinking about this issue though, in case transforms add a lot of overhead, I wonder now whether we need to provide any API or whether this could be an unexpected consequence of transforms that implementations need to deal with. > 1/ enqueue throw for some definition of "too large audioframe" If write is failing, it usually means the WritableStream will be errored, which we do not want. I guess an error event in RTCRtpScriptTransformer is a possibility if we want the web app to get that info fast, or a stat otherwise. > 2/ the original frame specify a maximum size? That is one possibility, another possibility is to put it at RTCRtpScriptTransformer level: ``` partial interface RTCRtpScriptTransformer { readonly attribute unsigned maxAudioFrameSize; } ``` with possibly an event in case the value changes. One question though is how to compute this value (MTU - estimated RTP packetization overhead?) -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/50#issuecomment-1715996471 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 September 2023 15:54:50 UTC