As specified in Google Congestion Control we should run the packet loss
estimation algorithm "every time feedback from the receiver is
received".
And, also as defined by GCC, we now have 2 different estimated bitrates,
one for the delay-based controller value and one for the loss-based one,
and we use the minimum value between those 2 as our current estimation.
[GCC]: https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02
1. Working scenario:
T1 -> Caps event (all caps have been received)
T1 -> Start discovering
T2 -> Change state to Playing
T2 -> The signaller is not started as:
- Sink current_state() == Paused as it will be set to
playing after the change_state vmethod returns
- Discovery is not done anyway
T1 -> Discovery is done
=> The signaller is started, and **everything works well**.
2. Failing scenario:
T1 -> Caps event (all caps have been received)
T1 -> Start discovering
T1 -> Discovery is done
T1 -> The signaller is not started as:
- Current state == Paused (it will be set to playing
after the change_state vmethod returns)
- Discovery is not done anyway
T2 -> Change state to Playing
T2 -> The signaller is not started as:
- Sink current_state == Paused as it will be set to
playing after the we return from the change_state
vmethod
In that case the signaller never starts.
Under certain circumstances one would like to use a self signed
certificate without the obstacles many browsers implement to
safeguard their users. One approach is to create a certificate
authority. One can now add this to the OS certificate store, or simply
add it to the browser. In the latter case one also needs to specify the
new authority on the webrtcsink. This commit enables this.
The change was merged inadvertently alongside the display-name
API extension, we will probably eventually expose API on webrtcsink
pads to control that, but we won't just set it to pad.name() anyway.
Fixes#33
We no longer connect to on-negotiation-needed, this in order to call the
consumer-added signal without holding the state lock:
Going to Ready triggers synchronous emission of the on-negotiation-needed
signal, during which time the application may add a data channel, causing
renegotiation, which we do not support at this time.
This is completely safe, as we know that at that point all conditions are
gathered: webrtcbin is in the Ready state, and all its transceivers have
codec_preferences.
