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

Re: RECAP: Conclusion: Cloning and sharing of MediaStreamTracks - worth it?

From: ᛏᚮᛘᛘᚤ <tommyw@google.com>
Date: Tue, 20 Aug 2013 14:42:32 +0200
Message-ID: <CALLKCfMNRFAuk+xDab5Og6W-3YD90+odSK94t15hChSthFxL0w@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
I haven't seen any real-world use cases that shows clearly that it is a
better solution to have a MST belonging to more than one MS.
If there are roughly the same pros and cons for both sides we should stick
with the previous version; it was worked this far just fine.


On Mon, Aug 19, 2013 at 10:28 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 08/15/2013 11:42 AM, Stefan Håkansson LK wrote:
>
>> On 2013-08-13 15:57, José Luis Millán wrote:
>>
>>> Harald said:
>>>
>>>  One still open question is whether a track can be a member of multiple
>>>>  streams; there are ease-of-implementation issues that argue for saying
>>>>
>>> "no"; there are orthogonality arguments that argue "yes".(If the answer
>>> is "no", I would argue that we should have a nullable "stream" property
>>> on the track, and that AddTrack throws an exception if the "stream"
>>> property of a track that's added is not null. That makes it predictable
>>> for the API what happens if you try to add a track to a stream.)
>>>
>>> Was it finally decided whether a track can be a member of multiple
>>> streams or not?
>>>
>> I think we never did formally decide, but my take of it is:
>>
>> * The current Draft says a track can be member of multiple streams
>> * Harald proposed it should not be allowed
>> * There was not really any consensus to change, so what is in the draft
>> is still valid
>>
>> Do you see it differently Harald?
>>
>>  That was my conclusion also; my worry was not so much which decision
> we'd take, but that we made an explicit decision one way or the other, so
> that we did not have to revisit the issue.
>
>
>
>
>
Received on Tuesday, 20 August 2013 12:43:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC