Re: Using tracks instead of streams

I think that from a solution point of view this is going in the right 
direction.

With my chair hat on I can worry about that this is a big re-design and 
that the schedule might slip a lot.

I also note that there is not much left in PeerConnection. If DTLS (as 
we discussed yesterday) keys can be individual per MST/transport, I 
think what remains is the list of ICE-servers (which could belong to the 
transport obj.) and the identity relating things.

Stefan

On 13/11/13 03:05, Justin Uberti wrote:
> 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 <mailto: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 <mailto: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
>
>

Received on Wednesday, 13 November 2013 09:38:37 UTC