Re: Update of Doohickey/AddTrack proposal

On Thu, Dec 19, 2013 at 10:12 AM, Martin Thomson
<martin.thomson@gmail.com>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.
>

Agreed. I was thinking that the stream could be obtained from the track,
which pushes this somewhat upstream to the MediaStream spec.

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