- From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Oct 2021 21:49:09 +0000
- To: public-webrtc-logs@w3.org
"WebRTC may not feel this pain as long as it always has software fallback w/ capabilities matching/exceeding that of the hardware path. Maybe that's a safe assumption?" [BA] WebRTC acknowledges the potential for hardware-only codecs in a few places. The basic model is laid out in Section 4.4.2: "If a system has limited resources (e.g. a finite number of decoders), createOffer needs to return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those resources. The session descriptions MUST remain usable by setLocalDescription without causing an error until at least the end of the fulfillment callback of the returned promise." Since both `createOffer()` and `createAnswer()` are async APIs, it is possible to interrogate the hardware so as to reflect the "current state of the system". In `getCapabilities()` (Section 5.2) there is a note stating that `getCapabilities()` should be consistent with the codec info returned in `createOffer()` and `createAnswer()`. In practice, if hardware codecs are discovered and returned by `createOffer()` or `createAnswer()` these will subsequently be reflected in `getCapabilities()`. If hardware resources are exhausted, the paragraph in Section 4.4.2 might be interpreted to imply that hardware-only codecs should be removed from `createOffer()`, `createAnswer()` and subsequent calls to `getCapabilities()`. Not sure if this happens in practice, though. In `setParameters()`, it is acknowledged that a codec may only be supported in hardware, and that resources may not be available for some configurations, in which case a "hardware-encoder-unavailable" error will be returned. Not sure if this happens in practice, either. -- GitHub Notification of comment by aboba Please view or discuss this issue at https://github.com/w3c/webrtc-svc/issues/49#issuecomment-954248659 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 October 2021 21:49:11 UTC