Re: Next steps on RTCRtpSender "doohickey" proposal

(as contributor) +1 from me.

One nit: The following should be legal:

addTrack(track, streamId1)
addTrack(track, streamId2)

this means that one track should be presented to the receiver as part of 
two streams.

I've recorded Justin's summary as part of bug 25497.


On 05/08/2014 06:34 AM, Justin Uberti wrote:
> Trying to bring this discussion to a conclusion... I sense consensus 
> around the following:
> - General concept of doohickeys, i.e. RTCRtpSender, RTPRtpReceiver.
> - addTrack(track, streamId)/removeTrack and onaddtrack.
> - Implicit cloning never occurs. This means that if you want to add a 
> track twice to a PC, you need to first clone it.
>
> More discussion is still needed on:
> - RTCRtpEncodingParams
> - RTCDtlsTransport
>
> Therefore I would like to advance the initial, uncontroversial parts 
> of this proposal, i.e. what I describe below. We can then discuss the 
> exact nature of the encodings and transport objects separately on the 
> list, and at the interim meeting.
>
> // the "send" doohickey
>
> interface RTCRtpSender {
>
>  readonly attribute MediaStreamTrack track;
>
> };
>
>
> // the "receive" doohickey
>
> interface RTCRtpReceiver {
>
>  readonly attribute MediaStreamTrack track;
>
> };
>
>
> // parameter to the onaddtrack event
>
> interface AddTrackEvent : 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
>
>  RTCRtpSender addTrack(track, streamId);  // replaces addStream; fails 
> if |track| has already been added
>
>  void removeTrack(RTCRtpSender);  // replaces removeStream
>
>  sequence<RTCRtpSender> getSenders();
>
>  sequence<RTCRtpReceiver> 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
>
> };
>
>
>

Received on Thursday, 8 May 2014 06:07:21 UTC