Re: Update of RTCRtpSender "doohickey" proposal

On 30/04/14 07:07, Justin Uberti wrote:
>
>
>
> On Tue, Apr 29, 2014 at 12:02 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     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.
>
>
> To help figure out the exact requirements of such an API, can you post
> an example use case?

I'll assemble something.

>
>
>     2) Would pc.addTrack(...) need success/failure indication? We have been
>     talking about that for addStream, but never really concluded.
>
>
> IIRC, the arguments for success/failure notification were about wanting
> to know if you had added more streams than you could send. However, I
> think in reality the act of adding a stream is only one of the things
> that could cause resource limits to be exceeded, so I think the error
> needs to come later, e.g. in setLocalDescription.

That is probably right. But I guess we need another error defined then 
(if I recall correctly we currently return a line no in the SDP where 
that could not be understood - but this is more of the type "not enough 
resources").

>
>
>     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.
>
>
> This is an interesting point, but I think the simplest thing is just to
> create a new, non-dead track on the remote side with the same ID.

I agree, this seems like the simplest way.

>
>
>     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 Wednesday, 30 April 2014 17:48:54 UTC