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

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

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 21 Aug 2013 07:34:15 +0000
To: Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <tommyw@google.com>
CC: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C37F776@ESESSMB209.ericsson.se>
On 2013-08-20 14:44, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
> 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.

There have been some use cases that would be easier to solve if a MST is 
allowed to belong to more than one MS, but I agree that it is more a 
question of orthogonality.

But if there are difficulties to implement support for allowing a MST to 
belong to more than one MS, of course that is something we must consider.

Just to understand, would the same difficulty arise in a situation 
looking something like:

* An app opens two PeerConnections to a peer app
* The app creates one MS and attaches it to both PCs
* At the peer app there will now (after some signaling) be two MS object 
with the same id, and both having MST's with the same id's (but being 
different objects).


> 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 <mailto: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 Wednesday, 21 August 2013 07:34:39 UTC

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