W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2015

Simplify the new addTrack() API

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Mon, 9 Feb 2015 14:26:35 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <A222C88B6882744D8D4B9681B315889023DAB128@ESESSMB307.ericsson.se>
Hi

With the introduction of RTCRtpSender/Receiver (Doohickeys), the way to
send and receive media will change. We used to add a MediaStream at one 
end, and dispatch a corresponding stream at the other end.

The new addTrack()-based approach is to add one MediaStreamTrack and
zero or more MediaStreams, containing the track, at one end, and 
dispatch a RTCRtpReceiver, the corresponding track and a list of 
MediaStreams, containting the track, at the other end. This implies 
creating a new stream if a certain stream isn't represented at the other 
side, or no stream was supplied for a track, and keeping handles to 
previously created streams to be able to add future tracks to them.

Even though the API call is named addTrack(), MediaStreams are very much 
involved with increased complexity as the cost. One reason for this is 
the need to polyfill the old addStream()-API on top of the new.

A different approach could be to keep the new addTrack()-API simple and
provide the API points needed to polyfill or implement advanced stream
handling in the application. For example:

addTrack(MST track, optional DOMString tag);

- The optional tag argument is a string that is signalled in SDP that 
contains application specific info. For example, a list of MediaStream 
ids. The corresponding event would expose the string the other side.

(Constructor) MediaStream(DOMString id);

- Construct a stream with a given id.

Feedback and suggestions are welcome.

/Adam
Received on Monday, 9 February 2015 14:27:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC