Skip to content
This repository has been archived by the owner on Mar 22, 2022. It is now read-only.

Remove deprecated offer_to_receive_xxx options #75

Closed
djee-ms opened this issue Sep 17, 2019 · 1 comment
Closed

Remove deprecated offer_to_receive_xxx options #75

djee-ms opened this issue Sep 17, 2019 · 1 comment
Labels
clean-up Code clean-up and refactoring

Comments

@djee-ms
Copy link
Member

djee-ms commented Sep 17, 2019

From #51:

Not sure about if it has any effect on performance, it could also be interesting to be able to modify lines 275-276 and 291-291 in peer_connection.cpp

options.offer_to_receive_audio = true;
options.offer_to_receive_video = true;

Now this is a special case for my implementation, but I only either send OR receive video/audio on each peer connection, so previously to this plugin, I modified offer_to_receive_audio/video to false depending on the connection. I also changed sendrecv in the sdp to sendonly or recvonly depending on the use-case.

Those options are deprecated anyway, so should be removed entirely. This mainly needs testing.
@djee-ms djee-ms added the clean-up Code clean-up and refactoring label Sep 17, 2019
@djee-ms djee-ms mentioned this issue Sep 17, 2019
Closed
@djee-ms
Copy link
Member Author

djee-ms commented Oct 17, 2019

Note to self : this changes the behavior of TestAppUWP in that creating an offer without any track will prevent the remote peer from sending its audio/video track, so TestAppUWP should be updated to add some transceivers in advance to accept those audio/video tracks, and there's no API for that at the moment.

djee-ms added a commit to djee-ms/MixedReality-WebRTC that referenced this issue Feb 6, 2020
@djee-ms
Remove old forced offer/answer for A/V
de76fe1 
Remove the forced audio and video offers to avoid messing with the tracks
and transceiver IDs.

Bug: microsoft#75
@djee-ms djee-ms mentioned this issue Feb 7, 2020
Open
djee-ms added a commit to djee-ms/MixedReality-WebRTC that referenced this issue Feb 26, 2020
@djee-ms
Add transceiver API to C++
b2aaf31 
This is part 1/N of the change, see global description below

----

Add standalone media track objects in both the C++ and C# library.
This enables supporting multiple audio and video tracks per peer
connection.

For local tracks, the `PeerConnection` interface is updated such that
the functionality of `AddLocalAudioTrackAsync()` and
`AddLocalVideoTrackAsync()` is split in 2 steps:

- the creation step, whose interface is on the local track object
itself, creates a standalone track object not associated with any peer
connection and not currently used by anything.

- the association step, which takes the track and attach it to a peer
connection via a transceiver.

For remote tracks, the `TrackAdded` and `TrackRemoved` events now
generate a new remote track object, which is passed to the event handler
as argument. The C# `PeerConnection` object also now keeps a list of all
the tracks attached to it, which can therefore be enumerated.

Because tracks are standalone objects, methods like
`PeerConnection.SetLocalAudioTrackEnabled()` are replaced with a
property `LocalAudioTrack.Enabled`, providing a more familiar pattern to
C# developers.

One important change required for remote tracks to be
paired by name is removing the legacy options
`RTCOfferAnswerOptions::offer_to_receive_video = true` and
`RTCOfferAnswerOptions::offer_to_receive_audio = true` from
`CreateOffer()` and `CreateAnswer()`. This change (see microsoft#75) has larger
implications that it looks when using Unified Plan (default), as
previously those options were implicitly making an offer to receive some
media, whereas this step is now explicit and the user needs to add some
transceiver in receive-only or send-receive mode before making an
offer/answer to allow the remote peer to send.

A new Unity demo `StandaloneDemo` shows how to use multiple tracks
between two peers. The demo is standalone in the sense signaling is
hard-coded and does not require an external node-dss server or any other
signaling solution.

Bug: microsoft#152
@djee-ms djee-ms mentioned this issue Feb 26, 2020
Merged
djee-ms added a commit that referenced this issue Mar 4, 2020
@djee-ms
Add transceiver API to C++
ba75e79 
This is part 1/N of the change, see global description below

----

Add standalone media track objects in both the C++ and C# library.
This enables supporting multiple audio and video tracks per peer
connection.

For local tracks, the `PeerConnection` interface is updated such that
the functionality of `AddLocalAudioTrackAsync()` and
`AddLocalVideoTrackAsync()` is split in 2 steps:

- the creation step, whose interface is on the local track object
itself, creates a standalone track object not associated with any peer
connection and not currently used by anything.

- the association step, which takes the track and attach it to a peer
connection via a transceiver.

For remote tracks, the `TrackAdded` and `TrackRemoved` events now
generate a new remote track object, which is passed to the event handler
as argument. The C# `PeerConnection` object also now keeps a list of all
the tracks attached to it, which can therefore be enumerated.

Because tracks are standalone objects, methods like
`PeerConnection.SetLocalAudioTrackEnabled()` are replaced with a
property `LocalAudioTrack.Enabled`, providing a more familiar pattern to
C# developers.

One important change required for remote tracks to be
paired by name is removing the legacy options
`RTCOfferAnswerOptions::offer_to_receive_video = true` and
`RTCOfferAnswerOptions::offer_to_receive_audio = true` from
`CreateOffer()` and `CreateAnswer()`. This change (see #75) has larger
implications that it looks when using Unified Plan (default), as
previously those options were implicitly making an offer to receive some
media, whereas this step is now explicit and the user needs to add some
transceiver in receive-only or send-receive mode before making an
offer/answer to allow the remote peer to send.

A new Unity demo `StandaloneDemo` shows how to use multiple tracks
between two peers. The demo is standalone in the sense signaling is
hard-coded and does not require an external node-dss server or any other
signaling solution.

Bug: #152
@djee-ms djee-ms closed this as completed May 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
clean-up Code clean-up and refactoring
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@djee-ms