- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Nov 2024 20:26:06 +0000
- To: public-webrtc-logs@w3.org
> * the API was intentionally designed to be cumbersome. As also noted in the mozilla position letting JS decide is not a great idea. But as the list-of-doom of hardware-acceleration related issues showed (and it has grown since) it is a practical problem. Understood. The updated Mozilla position is we'd rather align with WebCodecs at this point. Trading a prescriptive method for a declarative API should suffice to let UAs that so wish apply the same fingerprinting mitigation heuristics here and in WebCodecs. This might include not honoring combinations of different values in the same top-level context, giving the same protections as the one-way top-level pageload gate suggested for the existing API. > * The API was for both senders and receivers (or encoders and decoders respectively). Encoders are typically the source of the issues like undershooting Thanks, I've updated the proposal to include RTCRtpSender as well! > * Does Firefox have hardware encoder and decoder support? Playback decode on all platforms. WebRTC on android where allow-listed. [Behind pref](https://bugzilla.mozilla.org/show_bug.cgi?id=1717679) on other platforms right now due to issues. Not sure about hardware encode. > * What concrete issue do you have with decoders? Most of the time the issues are related to rate control and undershooting but that is on the encoder side I meant to include encode as well. Now updated. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/229#issuecomment-2479861118 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 November 2024 20:26:08 UTC