- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Sep 2022 09:59:15 +0000
- To: public-webrtc-logs@w3.org
You're dealing with two cases: 1/ generating a keyframe for all layers. Can be done either as `generateKeyFrame()` or a series of `generateKeyFrame(rid)` 2/ preemptively generating a keyframe for the lower two of the three layers in a simulcast stream because you know you are about to turn of the "high" layer. Using an array of rids has several advantages: 1 / the call from JS to the encoder is "heavy" and requires multiple thread hops. 2/ if you require separate calls you may end up in situations where you generate a keyframe on one layer and set the flag to generate a keyframe on the second layer only on the next picture. 3/ The encoder may be able to optimize encoding if the layers are in sync which is generally desirable, see [here](https://bugs.chromium.org/p/webrtc/issues/detail?id=10107#c4) (if it is an encoder that actually understands the concept of simulcast). Making this decision in the encoder which has a lot of context seems preferable. In general I doubt the value of resolving the promise with a timestamp. In RTC, generating keyframes is subject to bitrate budget which is why both [RFC 4585](https://www.rfc-editor.org/rfc/rfc4585.html#section-6.3.1) and [RFC 5104](https://www.rfc-editor.org/rfc/rfc5104#section-4.3.1.2) make it clear that the receiver may ignore such requests. Your promise may resolve later than you think and you can not distinguish between a keyframe generated by the API call and one generated by RTCP feedback anyway. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/146#issuecomment-1241765265 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 9 September 2022 09:59:17 UTC