- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Apr 2025 18:22:21 +0000
- To: public-webrtc-logs@w3.org
Repasting my comment on the other GitHub issue: > If depacketizer is not processing video packets, reject promise with [InvalidStateError] (https://webidl.spec.whatwg.org/#invalidstateerror), abort these steps. The intent of the spec is about the depacketizer being video or audio, not whether it is processing packets at the moment of the sendKeyFrameRequest call, which happens in a different thread. There are 3 threads: The depacketizer packets, where packets are flowing The window thread where the transceiver state is exposed The worker thread where this API is called We cannot in the worker thread make a check on a state that is valid in one of the two other threads. If we really want to check this state, we would need to put that check in an in parallel section, and we would need justification for this. > Furthermore, this change would render all browsers except Safari non-conformant, so this change is not Web compatible. How could that be not web compatible given Safari has been the first to ship this API a while ago? AFAIK, Chrome is not shipping this API. I am not sure where Firefox is. Also, throwing less is web compatible, starting to throw is more difficult. If we are talking about web compatibility, it should play in favour of this CL. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/243#issuecomment-2770329959 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 April 2025 18:22:22 UTC