Re: Update of Doohickey/AddTrack proposal

On Thu, Dec 19, 2013 at 6:12 AM, Göran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

>  Hi!
>
>
>
> Nice going! The addition makes the pipeline clearer in my mind!
>
>
>
> However, haven’t we had discussions about also have API support for
> managing the bitrate (and pattern) in absolute terms on track and
> transport/peerconnection level? It was not obvious in Your proposal if and
> how
> that is supported. Was something dropped in cut and paste, J:
>
>   // for multiple encodings: simulcast (audio or video), layered coding
>
>   // specify the codec to use, resolution, bitrate, and any dependencies
> for each encoding
>

>
> Did You have in mind adding such stuff, e.g. absolute bandwidth allocation
> on outgoing flows and as well as caps in aggregate of outgoing flows on
> individual Transport path?
>

We haven't converged on exactly how that should be done. This is my
high-level proposal on how this could be done, and also handle things like
simulcast at the same time. I omitted most of the details on the exact
parameters to avoid distracting from the overall Sender/Receiver concept
that I was trying to put forth.

>
>
> Right now, I am leaning towards having this in WebRTC 1.0 would add to its
> viability for mobile deployment but I would like to hear what others have
> in mind.
>
>
>
> Regards
>
> Göran
>
>
>
>
>
> *From:* Justin Uberti [mailto:juberti@google.com]
> *Sent:* den 19 december 2013 04:36
> *To:* public-webrtc@w3.org
> *Subject:* Update of Doohickey/AddTrack proposal
>
>
>
> 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.
>
>
>