Issue metadata
Sign in to add a comment
|
RTCPeerConnection.getLocalStreams() should return all streams of all senders |
||||||||||||||||||||||||
Issue descriptionWe implement the non-standards addStream/removeStream which add and remove from a set of streams that can be gotten with getLocalStreams. When addTrack/removeTrack/replaceTrack is added, the relationship between streams and tracks are not defined by a set of "local streams" but by a set of senders. Multiple senders might send the same track or the same sender might be associated with multiple streams (lower layer only supports 1 stream per sender at the moment though). In order to match Firefox's behavior, addTrack with a stream should add to the set of local streams, and removeTrack/replaceTrack might remove from it. getLocalStreams() should be implemented by iterating senders and looking at their associated streams. Only when the number of senders using a particular stream reaches zero should it no longer be included in the result.
,
Jul 3 2017
Firefox polyfills so that addStream is equivalent to looping through tracks of the stream and doing addTrack(track, stream). When getLocalStreams() is compatible with this we should define our addStream and removeStream the same way, if possible.
,
Jul 3 2017
,
Jul 18 2017
@comment #1: Sounds good to me. The less layers we can keep the "legacy" methods in, the better. Though I doubt "local_streams()" is something we can trivially remove; probably will require a PSA.
,
Aug 14 2017
Changing milestone to M62. Please correct if that's wrong.
,
Aug 29 2017
,
Sep 13 2017
Issue 764414 has been merged into this issue.
,
Jan 17 2018
I expect this to be done within a milestone once started, but if we prioritize transceivers over deprecating/removing legacy this may be further bumped to 67+.
,
Jan 17 2018
,
Jan 29 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by hbos@chromium.org
, Jul 3 2017