Re: Using tracks instead of streams

Martin's proposal is exactly what I was thinking. Let me go a step futher:

I suggest we call the SendDoohickeys MediaStreamTrackSenders and the
corresponding receive-side objects MediaStreamTrackReceivers.

For getting access to ICE/DTLS info, both MSTSenders and MSTReceivers can
also have a reference to a Transport object, which will have its own state
variables, including the RTCIceConnectionState of that particular
transport, and the .remoteCertificates for the DTLS connection.

so we end up with something like:

interface Transport {
  attribute RTCIceConnectionState state;
  attribute sequence<ArrayBuffer> remoteCertificates;
};

interface MSTSender {
  attribute MediaStreamTrack track;
  attribute Transport transport;
  // and some other stuff
  attribute bool active;  // or suspended, I forget
  attribute PriorityLevel priority;
  attribute unsigned long maxBitrate;
  // ellipsis
};

interface MSTReceiver {
  attribute Transport transport;
  attribute MediaStreamTrack track;
  // and some other stuff
};

interface PeerConnection {
  MSTSender addSender(MST);  // if called multiple times with the same MST,
it's a simulcast!
  void removeSender(MSTSender);  // see above for why this needs to take
MSTSender instead of MST
  attribute sequence<MSTSender> senders;
  attribute sequence<MSTReceiver> receivers;
};

for backcompat, addStream, removeStream, getLocalStreams, and
getRemoteStreams can be trivially polyfilled in JS, so there is minimal
impact on current applications.

in total, we have something like

Source ---> MST ---> MSTSender ---> Transport ---> (The Internet) --->
Transport ---> MSTReceiver ---> MST ---> <video/>



On Tue, Nov 12, 2013 at 1:25 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

> On 2013-11-12 09:54, Martin Thomson wrote:
> > On 12 November 2013 00:18, Adam Bergkvist <adam.bergkvist@ericsson.com>
> wrote:
> >> One thing that I find a bit odd is:
> >>
> >> pc.addSendTrack(track);
> >> pc.sendTracks[0] == track; // false (different types)
> >
> > It's more like:
> >
> > pc.addSendTrack(track) === pc.sendTracks[0];
>
> sendTracks should be called sendDooHickies in that case.
>
> >
> >> We could have the script construct a DooHickey and add it to the
> >> PeerConnection.
> >>
> >> // A-side
> >> var hickey = new DooHickey(track);
> >> peerConn.addDooHickey(hickey);
> >
> > That seems like busy work.  It also means that you can't make the
> > special linkage that a Doohickey needs with RTCPeerConnection.
>
> That's true; the special linkage could happen when the object is added
> to the RTCPeerConnection. But then we need to prevent the script from
> adding the doohickey to other RTCPeerConnections. That's perhaps not
> super great.
>
> /Adam
>
>