- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Oct 2024 09:36:22 +0000
- To: public-webrtc-logs@w3.org
Let me give you a brief recap since it has been a while: * 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. * The API was for both senders and receivers (or encoders and decoders respectively). Encoders are typically the source of the issues like undershooting * there was enough consensus to merge the PR, yet the "Mozilla position" (a conglomerate!) went the other way? * 2+ years later the suggestion is to go back to the drawing board? @jan-ivar, three questions: * how do you plan to address the (theoretical) fingerprinting concerns, e.g. by comparing decode times with and without hardware on different receivers (or senders) * Does Firefox have hardware encoder and decoder support? This is somewhat hard to determine since Firefox still lacks both [decoderImplementation as well as powerEfficientDecoder stats](https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=master&label=experimental&aligned) but the result of disabling the OpenH264 plugin suggests "no". * 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 -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/229#issuecomment-2443706108 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 29 October 2024 09:36:23 UTC