Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Partial removal of a track? #1609

Closed
henbos opened this issue Sep 19, 2017 · 3 comments
Closed

Partial removal of a track? #1609

henbos opened this issue Sep 19, 2017 · 3 comments
Assignees
@jan-ivar
Labels
PR exists

Comments

@henbos
Copy link
Contributor

henbos commented Sep 19, 2017

It is possible for a sender to have multiple streams, resulting in the other endpoint having a receiver with multiple streams.

Let's say we signal that track1 belongs to stream1 and stream2. Is it OK to then signal that the track belongs to another set of streams - let's say stream1, but no longer stream2? In this case, it should be removed from one stream and the receiver's set of associated streams should be updated, but the track should not be muted.

The spec is currently written to "process the removal of a remote track" which set the receiver's associated streams and mutes the track (if not already muted).

If this is to be supported, I believe we need to either:

  • If this counts as the removal of a track, the description should be updated to say only mute if the receiver's set of associated streams is empty.
  • If this does not count as the removal of a track, we need to add a step to update the set of associated streams of receivers that are not removed.

I'm no SDP guru, is my understanding of this correct?
@taylor-b
Copy link
Contributor

taylor-b commented Sep 22, 2017 •
edited

I suppose this should be supported. It's not possible to change a sender's set of streams via the API, but it's possible to change a receiver's via SDP munging.

The "removal of a track" steps are only invoked when the direction changes to "sendonly" or "inactive" (meaning, when the track can no longer be received unless renegotiation occurs). So if we want this to supported, we'd need to add an additional step for checking if the set of streams changed and updating them accordingly. I assume this is what you're referring to when you say:

add a step to update the set of associated streams of receivers that are not removed.

@henbos
Copy link
Contributor Author

henbos commented Sep 25, 2017

Yes. Should we have an event on the receiver that fires saying streams updated?

@taylor-b
Copy link
Contributor

taylor-b commented Sep 25, 2017 •
edited

Sure, I don't see why not.

taylor-b added a commit to taylor-b/webrtc-pc that referenced this issue Jun 20, 2018
@taylor-b
Update a receiver's set of remote streams when "a=msid" lines change.
0425caa 
Fixes w3c#1609.

This PR updates the `[[AssociatedRemoteMediaStreams]]` slot in every
`setRemoteDescription` call, even if the direction isn't changing, and
also adds:

- A `getStreams()` method to `RTCRtpReceiver`, just returning the value
  of the internal slot.
- A `streamsupdated` event, to tell when the set of stremas changes.
  Fired at the end of `setRemoteDescription` like everything else.
@taylor-b taylor-b mentioned this issue Jun 20, 2018
Closed
@jan-ivar jan-ivar mentioned this issue Jul 25, 2018
Merged
@jan-ivar jan-ivar assigned jan-ivar and unassigned taylor-b Jul 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jan-ivar jan-ivar

Labels
PR exists
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@aboba @jan-ivar @henbos @taylor-b