Re: addTrack/removeTrack on gUM streams and PeerConnection remote streams from Martin Thomson on 2013-04-17 (public-media-capture@w3.org from April 2013)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 17 Apr 2013 14:43:24 -0700
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <CABkgnnWY2Ugat0hPRSVR4Rj6G-wdsAeCm8FqryhX3h7-Q1pPPw@mail.gmail.com>

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.

Received on Wednesday, 17 April 2013 21:43:51 UTC