* Resolve newer participant using higher precision join time.
Also, keep it consistent based on participant SID if everything else is
the same.
* switch to compare semantics
* fix
* Do not seed if stream is already writable.
It is possible that in migration case, when the forwarder state is
fetched from migrating out node and used to seed downtrack, it has
already started due to the time it takes to get the state. Seeding in
that state will reset things and cause large sequence number gaps
potentially.
* do not take lock
* Debug FF TWCC
* - TURN off TWCC for Firefox. Seems to fail with VP9 send, i.e. there are
no TWCC feedback packets when sending VP9.
- Relax thresholds for congestion as staging data is showing
oscillations.
- Clean up some logging.
* debug log a few more signal messages
* revert config
* revert config
* clean up
Seeing some negative loss count (seems to be when interacting with
Firefox, but don't have definitive proof it does not happen with
others). Debug logging a bit to understand what could cause it.
Also, consolidating some common code to process packet feedback.
* move unrolled mime type check for broader use
* Use in IsSvcCodec and make MimeType exported
* test
* tidy branches
* tidy
---------
Co-authored-by: Paul Wells <paulwe@gmail.com>
* 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
