Re: Update of RTCRtpSender "doohickey" proposal

I like this. I have a couple of questions/comments though:

1) I'd like to see already for version 1 surface for a way to check if 
media is flowing (RTP packets are being sent) on the RTCRtpSender. 
Martin mentioned this yesterday.

2) Would pc.addTrack(...) need success/failure indication? We have been 
talking about that for addStream, but never really concluded.

3) I like the removal of the "removetrack" event, instead having the 
track on the remote side going to ended state. I guess the associated 
RTCRtpReceiver would also go to a terminated state. We need some text 
explaining what will happen if the same track is again added on the 
sender side.

4) I remain unconvinced that we need the stream argument for addTrack. I 
think the really simple cases can be polyfilled anyway (assume all 
tracks belong to one stream), and it does not help the advanced cases.

Stefan

On 28/04/14 18:00, Justin Uberti wrote:
> Update of the proposal from earlier this year, addressing the feedback
> from the list. Mainly, the issues with AddStream and AddTrack have been
> resolved by adding an explicit |stream| parameter to AddTrack.
>
>
> ------------------------------------------------------------------
>
>
> I suggest we call the SendDoohickeys RTCRtpSenders and the corresponding
> receive-side objects RTCRtpReceivers. 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 RTCRtpSender as a return value from AddTrack (which replaces
> AddStream). You get a RTCRtpReceiver as an argument to the new
> onaddtrack callback (which replaces onaddstream). The actual track
> object can be obtained as a property from the RTCRtpReceiver (see below).
>
>
> For getting access to ICE/DTLS info, both RTCRtpSenders and
> RTCRtpReceivers can also have a reference to a RTCDtlsTransport 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:
>
>
> // used with RTCRtpSender
>
> interface RTCDtlsTransport {
>
>   attribute RTCIceConnectionState state;
>
>   sequence<ArrayBuffer> getRemoteCertificates();
>
>   //... more stuff as needed
>
> };
>
>
> // used with RTCRtpSender
>
> interface RTCRtpEncodingParams {
>
>     double               priority = 1.0;  // relative priority of this
> encoding
>
>     unsigned int       maxBitrate = null;  // maximum bits to use for
> this encoding
>
>     boolean             active;  // sending or "paused/onhold"
>
> };
>
>
> // the "send" doohickey
>
> interface RTCRtpSender {
>
>   readonly attribute MediaStreamTrack track;
>
>   readonly attribute RTCDtlsTransport transport;
>
>   // 1-N encodings; in the future, N can be > 1, for simulcast or
> layered coding
>
>   // Each EncodingParams specifies the details of what to send (e.g.
> bitrate)
>
>   sequence<RTCRtpEncodingParams> getEncodings();
>
> };
>
>
> // the "receive" doohickey
>
> interface RTCRtpReceiver {
>
>   readonly attribute RTCDtlsTransport transport;
>
>   readonly attribute MediaStreamTrack track;
>
>   // more stuff as needed
>
> };
>
>
> // parameter to the onaddtrack event
>
> interface RemoteTrackEvent : Event {
>
>   readonly attribute RtpReceiver receiver;
>
>   readonly attribute MediaStreamTrack track;
>
>   readonly attribute MediaStream stream;
>
> };
>
>
> partial interface RTCPeerConnection {
>
> // because a track can be part of multiple streams, the id parameter
>
>   // indicates which particular stream should be referenced in signaling
>
>   RtpSender addTrack(track, streamId);  // replaces addStream
>
>   void removeTrack(RtpSender);  // replaces removeStream
>
>   sequence<RtpSender> getSenders();
>
>   sequence<RtpReceiver> getReceivers();
>
>   EventHandler onaddtrack;  // replaces onaddstream; event object is
> RemoteTrackEvent.
>
>                                          // note that onremovestream is
> not needed, since tracks are 'removed'
>
>                                          // simply by progressing to the
> ENDED state
>
> };
>
>
> 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 ---> DtlsTransport ---> (The Internet)
> ---> DtlsTransport ---> 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 DtlsTransport; N is controlled by
> the policy specified for BUNDLE.
>
>

Received on Tuesday, 29 April 2014 07:02:41 UTC