Re: Next steps on RTCRtpSender "doohickey" proposal

On 2014-05-08 08:07, Harald Alvestrand wrote:
> (as contributor) +1 from me.

Ditto.

>
> 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 still think that conveying the MediaStream(s) a track belongs to using 
SDP adds unnecessary complexity to the API and the solution.

But if we should, why not make the second (and optional) argument to 
addTrack a list of streamId's instead (I proposed that in [1])?

If you can call addTrack several times with the same track as first 
argument but different streamId's, what should happen at the far end if 
you carry out an SDP O/A between the calls?

[1] http://lists.w3.org/Archives/Public/public-webrtc/2014May/0009.html





>
> 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 07:43:56 UTC