Re: addTrack/removeTrack on gUM streams and PeerConnection remote streams

On 2013-04-18 09:37, Stefan Håkansson LK wrote:
> On 2013-04-17 23:43, Martin Thomson wrote:
>> On 17 April 2013 14:39, Robert O'Callahan <robert@ocallahan.org> wrote:
>>> On Thu, Apr 18, 2013 at 8:59 AM, Martin Thomson
>>> <martin.thomson@gmail.com>
>>> wrote:
>>>>
>>>> This sounds good to me.  I was going to go even further and suggest
>>>> that track sets in MediaStream could be made immutable, but that
>>>> changes the model we've been assuming too much.
>>>
>>>
>>> I don't think we can do that --- IIUC, gUM streams, PeerConnection
>>> remote
>>> streams and media-element streams can all dynamically add and remove
>>> tracks
>>> as the source progresses.
>>
>> That's may be true for PeerConnection, though it doesn't have to be,
>> depending on how we intend to resolve certain media path issues.  My
>> expectation for gUM was that the output would be stable from a track
>> perspective at least.  But you are right, it's probably unworkable.
>> My vain hope was to confine that sort of dynamism to processing-type
>> APIs.
>>
> I think the question of whether all MediaStream's could be immutable
> (i.e. not allow tracks to be added or removed) is partly up to
> implementers. I think we could live with that in a first version if very
> complex to support, but OTOH it seems that this is not the case based on
> the feedback so far.

That was very unclear. What I meant was that if adding/removing tracks 
was very complex to support, we could consider not supporting that in a 
first version. But we have not really heard that from implementers.

>
>
>

Received on Thursday, 18 April 2013 08:10:26 UTC