webrtcsink: improve encoder selection mechanism
At the moment, encoder selection in webrtcsink happens as follows:
-
webrtcsink
waits for caps from input stream - It then looks up encoders for the caps provided by the user, and runs "discovery pipelines" with them, stopping at the first functional one for each structure in the caps.
- Once a consumer connects, it is then offered all the codecs we found a functional encoder for
- The consumer then rules out any formats it wants, and we select the format at the top of the SDP, using whatever first functional encoder we found during the delivery phase.
This process works decently but has a critical flaw: some encoders may only allow for a limited number of concurrent instances before erroring out.
I think we should address the issue as follows:
- During the discovery stage, don't stop at the first functional encoder for a format, but instead construct a sorted list of functional encoders (we can still look up the SDP attributes at that point, I don't see a reason why those would change for a given encoder as long as the input caps don't).
- When a consumer connects, reserve an instance of a functional encoder for each format, by trying to set it to READY. If this fails, move to the next functional encoder for the format, if no functional encoder is available don't propose the format at all.
- Once the consumer has replied (or has been otherwise removed), release all resources we no longer need, keeping only one functional encoder if needed, bring the consumer pipeline to READY, add the encoder, move state up
The advantage of that solution is that it should work even when another process is trying to make use of "limited use" encoders.
Question: Can we consider that all "limited use" encoders can be reserved by simply setting them to READY, or will we have to possibly send caps / bring their state up to PAUSED to have them reserve resources?
Original issue: https://github.com/centricular/webrtcsink/issues/82