* Support XR request/response for rtt calculation
* Update pkg/sfu/downtrack.go
Co-authored-by: David Zhao <dz@livekit.io>
---------
Co-authored-by: David Zhao <dz@livekit.io>
* Remove subscriber if track closed while adding subscriber.
It is possible that the track is closed when subscriber add is
processed. That subscriber would have been dangling off a closed track.
Check again after adding subscriber if track is closed.
If it is, remove the subscriber and return error so that subscription
manager re-resolves.
* oops, wrong unlock
When a fallback is not applied, it is due to signal interruption.
ICE connection failing happens. And every time there is error, it is due
to "no selected pair".
Move all of it to `Debugw`. `setting ICE config` is the definitive log
which says if a different ICE config was applied.
* Maintain subscription count.
Does not affect function as it is not decremented only if limits are
configured. But, good to maintain proper count anyway.
* wire
Simplify a bit. Pending migratiion tracks need not be maintained as when
a migrated track is added, it is added to up track manager and treated
as a published track. When up track manager closes, published tracks
will close. So, no need to maintain a separate list.
* Buffer size config for video and audio.
There was only one buffer size in config.
In upstream, config value was used for video.
Audio used a hard coded value of 200 packets.
But, in the down stream sequencer, the config value was used for both
video and audio. So, if video was set up for high bit rate (deep
buffers), audio sequencer ended up using a lot of memory too in
sequencer.
Split config to be able to control that and also not hard code audio.
Another optimisation here would be to not instantiate sequencer unkess
NACK is negotiated.
* deprecate packet_buffer_size
* Reduce heap for dependency descriptor in forwarding path.
Marshaled dependency descriptor is held in sequencer adding heap objcts.
Store DD bytes in sequencer to avoid heap usage.
Also, accomodating over sized objects via storing in slice and using it
in case the bytes do not fit in the internal array.
NOTE: Marshal DD still does a make([]byte...), but I think it should be
on the stack given the short use of it. Have to verify.
* fix test and also add cases for oversized codec/dd bytes
It is possible that participant state and migration state updates are
racing. And a participant update could end up with no tracks when
migration is being processed.
Moving handling of migrated tracks to when the migration state moves to
completed. Pending data channel were already happening only on complete.
Move tracks also to that point.
Handling it earlier meant that track published callback happened and
ownership of track moved to new node before the new node could finish
peer connection. So, in cases where migration did not go through, this
caused confusion of track ownership.
* Remove some logs.
Also, changing Errorw -> Warnw in a bunch of places.
Going to move towards using `Errorw` for cases where a functionally
unexpected condition happens, i.e by design a condition should not
happen yet it triggered kind of scenarios.
* log error
Unless there are no published tracks, declare connected on primary PC
connected.
Streamlining this a bit. A bit of history
- With original migration, migration complete was declared on all tracks
published.
- When muted tracks has to be migrated, a publish is synthesised for
muted tracks, but migration complete did not wait till publisher peer
connection connected.
- A few weeks back, those paths were merged and all cases were changed
to use synthesised publish.
- Previously the completion point was different between muted and
unmuted tracks. And with the change to treat everything like a muted
track, completion point changed.
Change it so that if publisher PC is expected to be active, wait for it
to be connected before declaring migration complete.
Firefox on Windows 10 seems to be producing simulcast tracks with
duplicate RID. That causes a leak as only one buffer is processed.
Ignore duplicate rid.
NOTE: This is not perfect as the actual layer -> rid is indeterminable
at addition time. It would require looking at packets to determine the
video dimensions and match to rid/layer to figure out which one is
correct and which one is duplicate.
To simplify though, taking the first one and dropping later ones.
This could mean the correct resolution is not streamed, but that should
be okay. The leak is far more destructive.
