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.
Make control decisions based on packet loss closer in intent to
the algorithm described in gcc section 6., and raise the threshold
for decreasing the bitrate based on delay_factor
Naive heuristic lifted from an earlier proof of concept,
augmented with logic from
https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02#section-5.5
A property is exposed to disable congestion control for
testing purposes, it can be extended in the future to allow
selecting a different congestion control scheme.
+ Update the documentation
