W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2013

Re: Update of Doohickey/AddTrack proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 19 Dec 2013 22:45:53 +0100
Message-ID: <52B36911.4090802@alvestrand.no>
To: public-webrtc@w3.org
On 12/19/2013 07:12 PM, Martin Thomson wrote:
> I think that you need to talk a little bit about how you plan to
> manage the difference between send and receive tracks.
>
> The onaddtrack (which I think would be even clearer as onremotetrack)
> needs a description of its arguments.  I think that those should be:
>
> interface RemoteTrackEvent : Event {
>    readonly attribute RtpReceiver receiver;
>    readonly attribute MediaStreamTrack track;
>    readonly attribute MediaStream[] streams;
> };
>
> The stream here is important.  This makes onaddstream polyfill
> actually possible.  It's otherwise impossible to learn what stream is
> being sent.  The fact that a single track can be part of multiple
> streams means that you need this to be cardinality n.

If the track has a property saying which streams it is in (which our 
implementation found that it needed internally when a track could be a 
member of multiple streams, so it's easy to expose it through the API), 
the RemoteTrackEvent doesn't need the MediaStream[] streams property.

>
> On 18 December 2013 19:35, Justin Uberti <juberti@google.com> wrote:
>> Based on some feedback I've received, I've slightly updated my proposal
>> (originally inspired by Martin) on doohickeys and replacing AddStream with
>> AddTrack. See below:
>>
>> ------------------------------------------------------------------------
>>
>> I suggest we call the SendDoohickeys RtpSenders and the corresponding
>> receive-side objects RtpReceivers. These objects allow control of how a
>> MediaStreamTrack is encoded and sent on the wire, including "hold" state,
>> prioritization, and multiple encodings (e.g. simulcast).
>>
>> You get a RtpSender as a return value from AddTrack (which replaces
>> AddStream). You get a RtpReceiver as an argument to the new onaddtrack
>> callback (which replaces onaddstream). The actual track object can be
>> obtained as a property from the RtpReceiver (see below).
>>
>> For getting access to ICE/DTLS info, both RtpSenders and RtpReceivers can
>> also have a reference to a DtlsTransport object, which will have its own
>> state variables, including the RTCIceConnectionState of that particular
>> transport, and the .remoteCertificates for the DTLS connection. This allows
>> applications to monitor the state of individual transports, as well as
>> inspect the certificates for individual transports.
>>
>> The actual interface is as follows:
>>
>> interface DtlsTransport {
>>    attribute RTCIceConnectionState state;
>>    attribute sequence<ArrayBuffer> remoteCertificates;
>>    //... more stuff as needed
>> };
>>
>> interface RtpSender {
>>    readonly attribute MediaStreamTrack track;
>>    readonly attribute DtlsTransport transport;
>>    // various tweakable attributes
>>    attribute bool active;  // controls "am I sending RTP"
>>    attribute PriorityLevel priority;  // for relative bandwidth allocation
>>    // for multiple encodings: simulcast (audio or video), layered coding
>>    // specify the codec to use, resolution, bitrate, and any dependencies for
>> each encoding
>>    attribute sequence<EncodingParams> encodings;
>> };
>>
>> interface RtpReceiver {
>>    readonly attribute Transport transport;
>>    readonly attribute MediaStreamTrack track;
>>    // more stuff as needed
>> };
>>
>> partial interface PeerConnection {
>>    RtpSender addTrack(MST);  // replaces addStream
>>    void removeTrack(RtpSender);  // replaces removeStream
>>    readonly attribute sequence<RtpSender> senders;
>>    readonly attribute sequence<RtpReceiver> receivers;
>>    EventHandler onaddtrack;  // replaces onaddstream; onremovestream is not
>> needed
>> };
>>
>> For backcompat, addStream, removeStream, getLocalStreams, getRemoteStreams,
>> and onaddstream can be trivially polyfilled in JS, so there is minimal
>> impact on current applications.
>>
>> All together, the pipeline looks like this:
>>
>> Source ---> MST ---> RtpSender ---> Transport ---> (The Internet) --->
>> Transport ---> RtpReceiver ---> MST ---> <video/>
>>
>> Each RtpSender/Receiver references a single MST, although a single
>> RtpSender/Receiver can send/receive multiple encodings (e.g. simulcast).
>> There are N RtpSenders/Receivers per Transport; N is controlled by the
>> policy specified for BUNDLE.
>>
Received on Thursday, 19 December 2013 21:46:05 UTC

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