* Remove alloc in packet forwarding path.
Unlikely logger creation was doing allocs. Replace it with a function
like in rtpstats_receiver.go so that allocations do not happen
unnecessarily.
* variable rename
* one more place
* Start stream allocator after creating peer connection.
RTTGetter relies of peer connection being created/started.
Starting stream allocator before creating peer connection could race.
* set bwe interceptor
* Address another panic.
If receiver is not resolved yet, prevent race of access dummy receiver.
* reset callback only if there is receiver
* missed return
* Better naming/logging for send side bwe
* Check BWE congestion state before doing optimal allocation.
It is possible that BWE declares congestion, but the estimated bandwidth
may still be enough to accommodate all tracks. So, stream allocator
would still not in DEFICIENT state. On a new track allocation, it will
get optimal allocation although BWE is in congested state.
Take BWE congestion state into consideration before doing any track
allocation.
* get congestion state from BWE rather than caching it in stream allocator
* get states from update
* log contributing groups only when they are small in number
* get oldest group always
* notify only when estimate is dropping
* require stronger CTR down trend
* maintain min/max group
* relax thresholds to declare congestion a bit
* Thottle the publisher data channel sending when subscriber is slow
Avoid the publisher overwhelm the sfu data channel buffer when
the subscriber has lower receive bitrates. It will drop message
if the subscriber is considered too slow to block the entire room.
* Enable nack in mediaengine and disable it in transceiver as need
pion doesn't support per transciver codec configuration, so the nack of this session will be disabled
forever once it is first disabled by a transceiver.
https://github.com/pion/webrtc/pull/2972
There are cases where the probe result has enough headroom to up
allocate all deficient tracks. Mainly happens after a loss scenario
where the estimate is actually still high.
After boosting once, there was a check for the track to hit the desired
layer before boosting again. But, that is not really necessary. Can
boost target and forwarder should resolve to the latest target.
Removing that check in the forwarder.
Also, adding a gratuitous boost check in stream allocator periodic ping
when deficient to look for opportunities to boost.
The SetCodecPrefrences function will save codecs
to the transceiver and if the primary codec is not
support by the client, the saved codec will generate
rtx codec for the unsupported codec cause corrupted
sdp.
* Don't wait rtp packet to fire track
Create track from sdp instead of first rtp packet,
it is consistent with the browser behavior and
will accelerate the track publication.
* fix test
* WIP
* no worker
* fixes
* use congested packet groups
* oldest group
* markers
* WIP
* WIP
* WIP
* WIP
* WIP
* clean up
* fmt
* consolidate
* store last packet only for bwe extension cases
* Try up-allocation on neutral trend.
Some probes end up with neutral trend due to getting much estimates of
same value. It is okay to try up-allocating in those cases. Otherwise,
the stream allocator some times gets stuck and does not up-allocate at
all as all probes end up neutral.
Changing the name of the signal to `NotCongesting` to signify it is
either neutral or clearing.
* wait 5 RTT for probe to finalize
* trend detector object encoder
Reverting back to pre-refactor behaviour. Was trying to avoid doing
special treatment when in probe, but REMB values are hard to predict
and the NACKs as well.
So, freeze updates when congesting in probe till the probe is done.
Otherwise, further changes while probe is finalising sometimes causes an
invalid signal and tracks are not up allocated.
