Re: Changing track sources...

Martin Thomson wrote:
> This is only a problem for RTCPeerConnection because it negotiates
> streams based on MediaStream(Track) identifiers.  That's the real
> problem.

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

> Here's the solution that I propose:
>
> partial interface RTCPeerConnection {
>      void addStream(MediaStream newStream, optional MediaStream streamToReplace);
> };
>
> This of course has ramifications for how streams are handled.  It's
> still unclear whether a track identifier can change; and whether new
> streams and tracks are created when a stream is added to
> RTCPeerConnection.  c.f. Adam's proposal on Outgoing/Incoming streams.

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). I don't think all the msid stuff has been sorted out in 
mmusic, but as you've pointed out, the track identifiers can change 
here. Heck, the newStream might not even have the same number and kind 
of tracks as streamToReplace.

Even if the track lists matched, the points brought up elsewhere about 
hardware encoders in the camera apply: if you switch from a camera with 
a built-in hardware encoder to a source without one, and don't have a 
suitable software replacement (and probably even if you do), you'll 
likely want to re-negotiate the codecs.

If you can only switch by routing things through a ProcessedMediaStream 
object, then the RTCPeerConnection knows when the stream is first added 
that this is something it should be prepared for, and might choose, for 
example to always use a software encoder. I'm not sure how much of that 
should be guaranteed by the API (I'm sure Harald would view it as an 
implementation detail, even if apps might care very much if trying to 
use this feature has performance implications), but under your approach 
the implementation doesn't even have the information needed to make 
these decisions.

Received on Monday, 10 December 2012 07:41:39 UTC