Re: Changing track sources...

Martin Thomson wrote:
> I want to avoid having two ways to achieve the same end.  <video> has

That's a reasonable goal, but I think what you're actually suggesting is 
having N ways to achieve the same end, each applicable only in a single 
context.

> a clear solution for this.  Adding the ability to switch sources
> provides a second mechanism, and a change to the characteristics of

I think these two mechanisms are not the same, for a number of reasons. 
What happens, for example, when you change the video track but leave the 
audio track the same? I'm pretty sure I know what happens in our 
implementation, and the answer isn't that the audio track continues to 
play back seamlessly, whereas it would if done via the 
ProcessedMediaStream approach (there are lots more differences in the 
events that fire, time timeline properties, etc.---I am thinking 
non-linear editors here---but let's not go into those).

> the stream.  Could you enforce the peerIdentity constraint on the
> source replacement?

Now _this_ is an interesting question, and one that requires more time 
to think about than I have to spend writing this e-mail.

> RTCPeerConnection.  And I don't want to force applications into using
> the processing API for this simple case.

We don't necessarily have to use the whole processing API. Parts of it 
_are_ now redundant with the Web Audio API (though there's still no 
equivalent solution for video). But I think this sort of approach is a 
better design, and even a cut-down version focused on these use cases 
would be better than something RTCPeerConnection-specific (even if we 
have to do something RTCPeerConnection-specific to handle identity, I 
suspect it will be strongly similar to rules we'll need for cross-origin 
resources). So, I'm not necessarily saying "use this exactly" but "use 
something like this".

> 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.

I'm not following your argument here (it wasn't even clear to which API 
"this" refers to in the first sentence).

Received on Monday, 10 December 2012 18:54:10 UTC