Re: In defense of AddStream

On 2013-11-15 10:59, Harald Alvestrand wrote:> I know this may make me 
sound like an antediluvian, but still, someone's
 > got to say it...
 >
 > I like the doohickeys. I really do. But I fear that by adopting,
 > willy-nilly, a doohickey-centric model, rather than adding doohickeys to
 > the track/stream model, we're creating a huge amount of states with
 > subtle semantics that we really don't have the full perspective to sort
 > out - and without a corresponding benefit.
 >

It's good that you bring this up. A change like this should be 
motivated; I think it is.

 > The model we've been working on so far is this:
 >
 > MediaStreams are designed to fit with HTML5 Media objects. Their
 > semantics fit with the <audio> and <video> tags' semantics; one <video>
 > tag needs to be fed one and only one MediaStream. (to my mind, that's
 > the only argument in favour of MediaStreams - but it's an important one).
 >

I agree, MediaStreams fit very well with the media elements and for the 
output of recording as well (when you want to tie audio and video 
together in a container). But we have encountered more problems than 
benefits with MediaStreams when it comes to PeerConnection (more on that 
below).

 > When using a PeerConnection:
 > - Sender side attaches a MediaStream to a PeerConnection.
 > - Receiver side gets a stream, consisting of the same number, type and
 > content of MediaStreamTracks.
 >
 > When switching to an AddTrack model, we abandon that - the JS programmer
 > is free to add some tracks, all tracks or no tracks from a stream to a
 > PeerConnection.

Yes, that's totally up to the application.

 > Now the receiver gets some knowledge of existing streams on the sender
 > side, but has no way to know if he got all the tracks for each stream,
 > some tracks  for each stream, or just the knowledge that a stream
 > exists, but none of the tracks (but how would the sender be able to
 > cause that?). Or perhaps he knows nothing about the stream any more, and
 > has to invent his own? On what criteria?
 >
 > This makes the model for those who use streams at all more complex to
 > deal with. And what's the benefit?

Let's divide this into two different cases. First, when you communicate 
with a non-webrtc enpoint. In that case, there are no MediaStreams on 
the other side. We won't have to figure out what to do when we get a new 
SSRC, but we don't know which MediaStream it should belong to.

In the browser to browser case, there are more that one solution. In the 
simplest case where there are only one MediaStream at the sender side, 
then there's no problem. In more advanced cases it's rather easy for the 
application to announce the MediaStream with app signaling; it may just 
be a list of track ids for a particular MediaStream.

Further, we don't have to have a concept of MediaStreams in 
PeerConnection and that simplifies the signaling. The tricky case where 
the same MediaStreamTrack instance is added to two MediaStreams and sent 
over the same PeerConnection goes away.

 > The model of creating a doohickey and then adding it to a PC creates
 > even more complexity.
 > To my mind, the doohickey represents the properties of the association
 > between the track and the PeerConnection. If you create it before adding
 > it, you have to answer questions like:

That's correct. But in Martins proposal, the DooHickey is created when 
the track is added; it can't live as initially unconnected. I suggested 
to create it in advance, but we concluded that that wasn't a good idea. 
We do have to deal with DooHickey objects when the track is not sent 
anymore, but I don't think that is any harder than setting them in a 
unusable state.

 > - What is the doohickey's state when it's not attached to a PC?
 > - What happens if a doohickey is attached to more than one PC?

Not possible with the current approach.

 > - Can you detach a doohickey from a PC? If so, what happens to it?

Not unless the related track is removed, in which case the DooHickey 
goes into an unusable state.

 >
 > All this complexity can be avoided by saying that in order for a
 > doohickey to be created, it has to be born already knowing about its PC
 > and its track, and those linkages cannot be changed, ever.

I agree, and that's the current assumption.

var dooHickey = pc.addSendTrack(track);

/Adam

 >
 > My summary:
 >
 > - Yes, we need the doohickey.
 > - Adding pc.AddTrack makes life more complicated. We shouldn't do it
 > without a clear benefit, and at the moment, I don't see what the 
benefit is.
 > - Adding doohickeys that can live independently from a PeerConnection is
 > a Bad Idea, and we shouldn't do it.
 >
 > That's my opinions at the moment...

Received on Friday, 15 November 2013 11:53:55 UTC