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

Re: Track cloning behavior of MediaStream() constructor and addTrack()

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 20 Mar 2013 10:07:10 -0700
Message-ID: <CABkgnnX1dyHM6piDqe15UJcryVMmOmpTYH5F8Sot6CxmcZy5Uw@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: Jim Barnett <Jim.Barnett@genesyslab.com>, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 20 March 2013 00:24, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:
>> Then we can enforce a strict 1 source, 1 track, 1 sink cardinality
>> without strange and opaque behaviour.  Each track could have a 'sink'
>> attribute that exposes any existing attachment so that this limitation
>> is discoverable.  You can add text to the exception that recommends
>> .clone()-ing.
> Can you be more specific about the strange and opaque behavior?

The reason we settled on ensuring that tracks are duplicated was that
we didn't want to have tweaks to one track affecting other tracks.
Maybe that was the wrong decision, but I tend to think that the
following is a better model:

> [Source] ---> [Track] ---> [Sink]
>          \--> [Track] ---> [Sink]

What this does is reduce the cardinality to unity at the track level.
Sources and sinks still need to deal with multiple tracks, but that's
natural.  "1 to n" is much easier to manage than "m to n".
Received on Wednesday, 20 March 2013 17:07:38 UTC

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