- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 18 Apr 2013 09:37:57 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Robert O'Callahan <robert@ocallahan.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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.
Received on Thursday, 18 April 2013 07:38:21 UTC