Re: In defense of AddStream

On 16/11/13 00:44, Justin Uberti wrote:
> Martin and Adam already said most of what I was going to say. One
> additional comment...
>
>
> On Fri, Nov 15, 2013 at 1:57 AM, Harald Alvestrand <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> 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.
>
>     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 this is the only argument in favor of MediaStreams. Making
> MediaStreams a lightweight grouping mechanism, as proposed, allows
> MediaStream to be useful for this one purpose, and not get in the way
> everywhere else.

I have one additional argument for keeping MediaStreams. If you record 
something it is much more convenient to be able to record a combination 
of audio and video in a way that allows it to be played out (with A/W 
sync) sometime in the future.

So I think the MediaStream is the right level for the Recording API, and 
the blobs produced be the recorder works right away with the video 
element (since it is designed this way).

(Note I still thinks that dealing with MediaStreamTracks rather than 
MediaStreams when transporting live media over the network is better for 
many reasons)

>
>
>     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.
>
>     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?
>
>     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:
>     - 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?
>     - Can you detach a doohickey from a PC? If so, what happens to it?
>
>     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.
>
>     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 Saturday, 16 November 2013 05:57:35 UTC