- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Sep 2022 12:24:27 +0000
- To: public-webrtc-logs@w3.org
@alvestrand see my objection to the consensus on the list. This isn't a new request, see [here](https://bugs.chromium.org/p/webrtc/issues/detail?id=10615) * some encoders (libvpx?) prefer synchronizing because it allows sharing some work, see [here](https://bugs.chromium.org/p/webrtc/issues/detail?id=10107#c4), not prohibiting this seems useful * while PLIs are per-ssrc they may come as part of a compound packet (servers may aggregate even though because of libwebrtc bugs currently few do probably) hence you need some kind of API for those. Aggregating into a single call to the encoder seems useful for this too. We're essentially talking about  (where "enc" is an abstract encoder on the left, SEA is a "simulcast encoder adapter" which resolves rids or ssrcs to layers and "enc" is a concrete encoder implementation on the right) vs  vs, with some encoder implementation that understands what this simulcast thing is  Please note that there is heavy threadhopping on the left of the first "enc". Leaving how to fulfill the request for keyframes to the encoder implementation seems preferable. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/143#issuecomment-1262202415 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 September 2022 12:24:29 UTC