W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2013

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 17 Apr 2013 14:43:24 -0700
Message-ID: <CABkgnnWY2Ugat0hPRSVR4Rj6G-wdsAeCm8FqryhX3h7-Q1pPPw@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:40 UTC