W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

Re: Changing track sources...

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 10 Dec 2012 10:28:52 -0800
Message-ID: <CABkgnnWWL5=rXzUKkqCco-Jmwa_3JP+XC6Vdmr20HVTD4kx00g@mail.gmail.com>
To: "Timothy B. Terriberry" <tterriberry@mozilla.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 9 December 2012 23:22, Timothy B. Terriberry <tterriberry@mozilla.com> wrote:
> So you're saying we should solve the same problem over and over again for
> every MediaStream consumer (I am thinking of the recording API here).

I want to avoid having two ways to achieve the same end.  <video> has
a clear solution for this.  Adding the ability to switch sources
provides a second mechanism, and a change to the characteristics of
the stream.  Could you enforce the peerIdentity constraint on the
source replacement?

I believe that media processing is the ultimate solution for a lot of
these cases, but there are two things:  The identity constraints on
streams imply that something special is required for
RTCPeerConnection.  And I don't want to force applications into using
the processing API for this simple case.

> Well, I think one of the goals should be to allow replacing the source of a
> stream without renegotiation (at least in some set of reasonable scenarios).

As we know, that's something that might only be possible in a narrow
set of cases.  One advantage of an API like this is that it can
perform the necessary sanity checks and reject as necessary.
Switching at the source would reject a larger number of substitutions
due to being unaware of the full range of options available.  Sure,
one source might not have the same set of codecs, but if those codecs
were negotiated, the switch could still proceed.

Received on Monday, 10 December 2012 18:29:22 UTC

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