-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reuse transceivers in subscribe path #51
Conversation
LK-22 (https://linear.app/livekit/issue/LK-22/feature-pooled-transceivers-to-avoid-re-negotiation) Do not stop remote tracks. That would change `readyState` of track to `ended` and the corresponding transceiver cannot be reused. Instead use the `enabled` attribute of track to enable/disable remote tracks. Bumping up the protocol version that informs the server that client is capable of reusing transceivers. Testing: -------- Connect from Chrome. For remote side, connect/disconnect from Firefox several times and ensure the following - SDP does not grow (it has 4 sections as reported by chrome://webrtc-internals (version, data, audio, video) each time the remote side connects. - Media flows from remote side on every connection. Oddities: --------- - Chrome callback `ontrack` sends a track. When the remote side reconnects and the same transceiver is used, the callback does not contain the new track id. It retains what was returned in the first callback. Don't think it is an issue as we do not use that track id anywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great!
Don't think it is an issue as we do not use that track id anywhere.
It does pass us a new stream id though? I think that's the more important piece. FWIW, we do use the track id here, only if it's not already encoded in the stream id. (Room.onTrackAdded
)
const parts = unpackStreamId(stream.id);
const participantId = parts[0];
let trackId = parts[1];
if (!trackId || trackId === '') trackId = mediaTrack.id;
Co-authored-by: David Zhao <[email protected]>
@davidzhao Yes I verified that the stream id and the parsing gets the new information. I will verify it again just to be doubly sure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great! lg
Re-confirming that the stream id shows the right stuff on a reconnect/reuse of transceivers
|
LK-22 (https://linear.app/livekit/issue/LK-22/feature-pooled-transceivers-to-avoid-re-negotiation)
Do not stop remote tracks. That would change
readyState
of trackto
ended
and the corresponding transceiver cannot be reused.Instead use the
enabled
attribute of track to enable/disableremote tracks.
Bumping up the protocol version that informs the server that
client is capable of reusing transceivers.
Testing:
Connect from Chrome. For remote side, connect/disconnect
from Firefox several times and ensure the following
chrome://webrtc-internals (version, data, audio, video) each
time the remote side connects.
Oddities:
ontrack
sends a track. When the remote sidereconnects and the same transceiver is used, the callback does
not contain the new track id. It retains what was returned in the
first callback. Don't think it is an issue as we do not use that
track id anywhere.