Normalize the rids in SDP to known patterns.
Currently,
- LK protocol uses q;h;f
- Sean's OBS WHIP uses 0;1;2
As the ordering in SDP could be different, normalize to known order.
For RIDs not in the known set, just use it as is.
* SVC with RID -> spatial layer mapping
There are cases where an SVC track comes in with a RID.
As there is no RID announced in SDP, it maps to invalid layer.
Seems to happen with older browsers.
* test
The browser could send rtp packets of svc encoding without
DD extension while the sdp negotiates it, sfu detects extension
in rtp packet for this case.
* Add simulcast support for WHIP.
- General change to have rids be anything.
- One issue is rid ordering not matching quality ordering, will need
some dynamic layer quality determination for that.
* clean up
* deps
* test
* Add a trend check before declaring joint queuing region.
Seeing cases where the propagated queuing delay drops from one group to
next. Both groups are above threhold. It also recovers majority of the
time. So, introducing a trend check before declaring that queuing delay
is in joint queuing region. It is set 0.8 by default which means the
queueing delay should be trending up strongly before being declared
joint queuing region.
* deps
* Send initial participant update only after a participant becomes active.
There are cases where apps send data to remote participant as soon as
client emits `ParticipantConnected`. But, that time point would not have
a fully established client (i. e. the media connection + data channel
establishment is still in progress).
This PR changes the initial participant update to be sent from server
side only when a participant becomes `ACTIVE`, i.e fully connected
(media channel established and data channels open).
It is supported for clients using protocol version > 15.
@cnderrauber bumping up the protocol version in this PR. Move support is
also conditioned on protocol version > 15, but that PR did not ump
protocol version. Please let me know if there are issues bumping
protocol version.
* check for joining states in broadcast
* have to check on other participant
* test
* make helper for sending participant updates
* test
* make utility of pushAndDeque
* test
* consolidate getting other participants
* remove extra cast
* debug
* debug
* typo
* stop transceiver that is not bound
* logs
* log
* check for ever bound
* clean up
* clean up
* Call Broadcast in lock scope.
Seems like there is a possible window where things can hang forever
if a goroutine enters the Wait) after the lock is released but before
Broadcast gets called, it will never see that broadcast and will hang forever.
* RLock
* Revert "Audio uses signal SignalCid and SdpCid. (#3564)"
This reverts commit cdfbb106d1.
* Revert "Keep simulcast information tied to receiver. (#3563)"
This reverts commit ed5e2f16b2.
* Revert "chore(logs): log VLS type for VP9/AV1 (#3561)"
This reverts commit ad010cfc43.
* Revert "fix(video): determine svc/simulcast from SDP for advanced codecs (#3549)"
This reverts commit 15f565510c.
* chore(deps): update protocol
* Keep simulcast information tied to receiver.
`simulcast` flag in `TrackInfo` is at track lavel. With codec simulcast,
the primary codec (in most cases) is SVC and the backup codec is
simulcast. Back up codec publish changing the track info setting to true
meant that the primary receiver was treated as simulcast if a subscriber
for primary codec joined after the backup codec was published.
Keep track of simulcast flag in receiver.
Also, TrackInfo Cids are from signal. So, keep track of SDP cids
separately. The `simulcastTrackIds` map uses SDP cid. Clean up by all
the SDP cids of a track
* clean up
* clean up
* clean up
* clean up
* test
* Store SdpCid and IsSimulcast in Trackinfo
* clean up
* mock
* fix(video): determine svc/simulcast from SDP for advanced codecs
* fix(explicit-svc): cleanup
* fix(explicit-svc): remove from list on close/remove
* fix(explicit-svc): reorder VLS selection, cleanup
* fix(explicit-svc): todo comments for temporal layer selector
* fix(explicit-svc): remove from simulcastTrackIds even if client does not support unpublish
Seeing a lot of queuing delay based back offs. Trying a couple of things
1. Accept a bit more queuing.
2. An option to try a different pacer. Would like to try with pass
through. That will produce some out-of-order packets. Remains to be
seen if it will have a negative impact.
This happens due to improper track type.
One possible option is to check the mime type of the track and calculate
the size, but there are other places in the code which work off provided
track type. So, just doing a defensive fix. Have to review code for all
uses of type and how it affects things if client provides incorrect
type.
Seeing an error in an e2e test, after migration, no packets are
forwarded. The only reason seems to be payload type mismatch (assuming
there are no errors in the forwarding loop pulling packets from buffer).
So, logging some packet stats in forwarding loop.
* Use atomic to store codec.
It can change on up stream codec change, but not seeing any racy
behaviour with atomic access.
Reverting the previous change to mute with this change.
* no mime arg
Need to re-visit the bind lock scope and maybe make the codec/mime
atomic and access them without bind lock. But, doing a whack-a-mole a
bit first to move things forward. Will look at making them atomics.
With publish RED and subscribe Opus, the RTCP sender reports were not
sent to down track as publisher sender reports were not forwarded to the
down track.
Raja Subramanian