Re: [webrtc-extensions] Add API for exposing codec HW capabilities (hardwareAccelerated) (#21)

@drkron Presumably the reason to add promise-based methods `getEncoderCapabilites` to the `RTCRtpSender` and `getDecoderCapabilities` to the `RTCRtpReceiver` would be to deal with the issue of resource availability.  That is, within the current static `getCapabilities` method, indicating support for hardware acceleration does not provide any performance guarantees.  The hardware resources might be available when they are negotiated, or they might have already been consumed by another browser tab or another application, in which case a software implementation will be used instead, with potentially degraded performance. 

However, it is not clear to me how a promise-based method actually deals with the resource competition issue.  Are we assuming that the browser controls access to (some? all?) of the acceleration resources, and therefore can ensure that they are available at the time that the promise is resolved?  How does the application actually reserve the resources?  Does this have to be done with Promise.all to prevent a race where the resource is advertised, but then consumed prior to being claimed? 

GitHub Notification of comment by aboba
Please view or discuss this issue at using your GitHub account

Received on Friday, 21 February 2020 19:15:09 UTC