Re: [webrtc-encoded-transform] How to handle transforms largely changing frame size (#50)

@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