-
Notifications
You must be signed in to change notification settings - Fork 283
Add multi-track support to C# library via transceiver API #221
Add multi-track support to C# library via transceiver API #221
Conversation
This follows the change in the interop DLL.
Callbacks from native code (reverse P/Invoke) are invoked on the signaling thread and should not call into the native WebRTC API again. For the RenegotiationNeeded event, since it is common for the user to call CreateOffer() as a result of this event, move its call to a worker thread. In addition, delay the call until the C# Transceiver wrapper has been fully constructed (and its handle set) to avoid invoking an event with a partially-constructed object.
Wait until the SDP exchange is completed to continue testing, otherwise some RenegotiationNeeded event or other might be invoked due to SetRemoteDescription() in parallel of another call due to setting a transceiver direction, among other issues.
// Cannot run in UI thread on UWP because this will initialize the global factory | ||
// (first library call) which needs to be done on a background thread. |
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.
nit: not for this review, but this looks like a very easy pitfall, it might be better to have an explicit initialization call instead.
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.
Yes, although explicit call is quite tricky in Unity
libs/Microsoft.MixedReality.WebRTC/Interop/RemoteAudioTrackInterop.cs
Outdated
Show resolved
Hide resolved
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.
See comments
Media tracks attached to the peer connection are those tracks attached to an owned transceiver, so can be enumerated from them. This simplifies the implementation and avoid the need to keep track of those tracks explicitly.
Rely on peer connection callbacks during Close() to clean-up the remote tracks. Also fix a bug where those callbacks are fired after the tracks have been destroyed.
- Fix bug in implementation passing the wrong address as the data channel object handle, which results in stack corruption of the managed engine. - Drive data channel clean-up from the DataChannelRemoved callback, whether invoked from the user removing a data channel or from a data channel being removed/destroyed automatically by the implementation.
libs/Microsoft.MixedReality.WebRTC.Native/src/peer_connection.cpp
Outdated
Show resolved
Hide resolved
This is redundant with the Transceiver.DesiredDirection setter.
Like remote tracks, data channels are essentially owned by the peer connection, even if the user can manually initiate creation. Therefore make DataChannel a regular non-disposable class to avoid confusion with implementation destroying a data channel.
} | ||
|
||
internal void Destroy() | ||
internal void DestroyNative() |
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.
The call to GC.SuppressFinalize is unnecessary now, right?
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.
Fixed.
This is part 2/N of the multi-track support : C# library. See part 1 (interop; #202) for an overall description of the API changes.
Bug: #152