Re: [webrtc-encoded-transform] generateKeyFrame takes a "rid" argument, but is invoked with "rids" (#143)

What I am after is optimal operation in cases where application would like to dynamically maximise video fidelity for every receiver group, by having tight control over the target bitrates of individual RIDs. A practical example:
* 2+ RIDs are configured for low fidelity encodings, that target low capability receivers, running on poor/lossy networks
* 1+ RIDs are configured for high fidelity encodings, that target high capability receivers, running on good networks
* Target bitrates for all RIDs are dynamically configured based on the ever changing capabilities of receiver groups to maximise video fidelity across all N receivers.

With N growing big, the optimization exercise requires frequent changes both in target bitrates of every RID, but also in the number of receivers specific RID is targeted to serve. Consider a scenario that involves introducing receivers at a high pace (e.g. start of a larger conference). In this scenario there will be a number of receivers capable of consuming high fidelity encodings (due to their estimators having time to ramp up and stabilize), as well as continuous inflow of receivers capable of consuming different variants of low fidelity encodings (these groups will change a lot due to estimators ramping up and stabilizing around some values). Since applications would want to minimise the number of generated key frames on any encoding/RID, they would want to pace/aggregate the changes. In practice this would mean having multiple changes to apply in one go. In this example, most of the changes would target lower fidelity encodings (due to higher instability of these groups). Under these conditions it would be great to have ability not to penalise receivers consuming high fidelity stream(s). Hence the ask to not artificially limit the API surface.


-- 
GitHub Notification of comment by solmaks
Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/143#issuecomment-1262108363 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 10:51:36 UTC