* Promoting a few logs to Info
Also, adding a couple of more info logs which I will remove later
after some debugging.
* mime type
* Protect pause/max layer
* notify even if not bound
- Do not update jitter on padding only packet.
Padding only packet may not have proper timestamp.
If it does, it probably has the time stamp of the
last packet with payload. That will also affect
jitter calculation, i. e. wall clock time is moving,
but RTP time is the same.
- Do not send `onMaxLayer` changed on bind.
It was probably racing with update when max layer
is updated when adaptive stream is off. There is
no need to send that update as the default would
be OFF. It will be enabled when adaptive stream
subscription turns it on or when max layer is
set when down track bind happens and adaptive stream
is off.
* WIP commit
* Connection quality changes
- Fix Firefox showing poor quality
o The issue was that we were using max available layer and
calculating quality. The rationale being that even if
server sends dynacast messages, client may not implement
dynacast and still stream all layers. But, with Firefox
(maybe a Firefox bug), it sends some small amount of
data on layer 2 even when that layer is disabled.
Guessing it is probing (or actually we might be using
some small value for high layers as Firefox cannot turn off
layers). That higher layer gets used in quality calculation.
As the bit rate on that layer is extremely low, it yields low
score.
Fixed by considering the max expected layer. That is of most
interest. Yes, clients may ignore dynacast and stream all layers,
but, max expected is the one of interest. So, look for
quality in the max expected layer and not max available layer.
- Lots of clean up around connection quality stuff
o Use a dynamic scaling thing to ensure that we do not get bitten
by absolute values. Calculate best possible scenario score and
map that to maximum MOS score. This will ensure that different
codecs, different settings do not mess up the scoring. For example,
a client might use 1 Mbps for 720p, but a different client could
use 2 Mbps for 720p. As an SFU/infrastructure middlebox, we do
not have control over quality at those rates. We can only ensure
that streaming happens smoothly at those rates. So, in that
example, for client 1, 1 Mbps will map to MOS 5.0 and for client 2,
2 Mbps will map to MOS 5.0. Any impairments after that will
reflect in the score.
o Penalise for missing target layer by one level for one layer missed.
o Move tests to connection quality directory. The participant test
was not super useful.
* Add missed file
* Remove debug code
* use more constants and initialise normalisation factor
* rtcscore pointer
* Limit dynacast to video and media loss proxy to audio
Was looking at keeping the track type out of those modules
and do a check at a higher level, but it is a bit unwieldy.
So, adding checks to the modules.
Also, ensuring that media loss proxy does not reset unconditionally
every second. Audio RTCP happens once in 5 seconds or so.
So, if server proxied let say 2% at t = 5, t = 6 would have
proxied 0 loss which may or may not be true. So, ensure that
a report was received and proxy value is updated by an actual
report.
* Remove track type from modules
* Filter candidate after setting description
* comment
* Fix filtering candidates
- For offer/answer from remote, do filtering before setting remote
description so that Pion does not see filtered candidates
- For offer/answer originating from server, do filtering after setting
local description (comments in code) so that remote side does not
see filtered candidates.
- Make logging a little consistent and use right context.
* Comment
* TCP fallback config and UT (broken now)
* log SDP only when preferring TCP
* Remove TCP fallback test attempt
* WIP commit
* Refactor media loss proxy
* Use DynacastQuality and MediaLossProxy from MediaTrack
* fix test
* Remove unused param
* Remove unused interfaces
* Move interface methods to local
* Split out DynacastManager
* have to add codec to dynacast manager
* RUnlock
* fix restart
* Adding API to force quality and also maintain closed state
* Address PR comments
* Queue `AddTrack` if a published track is not yet closed
- Adding a queue for pending track by signal cid.
Ideally, there should not be more than one pending,
but making a queue to be generic.
- `TrackPublished` is sent if the queue has entries
when a published track is closed.
* Fix tests and add more checks for queueing AddTrack
* Use a go routine to clean up stats workers.
It is possible that certain events (like TrackUnpublished) can
happen after the participant is closed. For webhooks pertaining
to those events, need details like room name/id. So,reap stats
workers a little while after the participant left event happens.
* handle data race report
* log analytics worker reap
* debug log
With rapid changes to subscription settings, use of a goroutine
could end up processing dynacast needs for that subscriber in
a different order. So, record the susbcription needs of a subscriber
in the callback and process the data in a go routine.
* Do not hold lock while invoking resolver.
Resolver is in room and it will grab its lock.
It is called from partcipant when checking permissions.
Permissions processing uses the participant lock.
So, not a good idea to call a room function with
participant lock held. Avoid that.
Also, use a full lock in the add/remove subscription
path. This is to ensure that permissions path and
subscription path (like subscribing to new participant's
tracks) do not race. As subscriptions are queued now
on the subscriber side, this should be fine.
* Revoke path resolution in ops queue goroutine
* fix test
* Keep track of pending subscriber operations.
This is required to determine if a receiver does not have
any subscription.
* correct spelling of queuing
* lock around hasPermission
* Move subscribe/unsubscribe queue to participant.
As subscribe/unsubscribe operation can come from both
local media track or remote media track, participant
needs to have it.
* Remove comment
* Stop reneg timer on close
* address comments
* Send permissions update on subscribe.
The permission `allowed` update was happening only when
processing pending subscriptions (which happens only on
subscription permissions update).
It is possible that subscription happens through other
paths (like subscribing new participant to tracks).
In that path, we were checking if the track has permissions
and adding to pending. But, we were not checking if
the track is in pending and if it is in there, removing
in on successful subscription and sending an update.
Fix that.
* log more fields in error
