Re: Isolated tracks

Le jeudi 22 mai 2014 à 07:55 -0700, Martin Thomson a écrit :
> Based on the discussion at the meeting, these are the conclusions I took away:
> 1. We need to surface isolation properties:
> 
> partial interface MediaStreamTrack {
>   attribute boolean isolated;

You'll want this to be readonly (presumably).

>   attribute EventHandler? onisolationchange;
> };
> 
> isolated is true for cross origin, DRM'd, and peerIdentity streams.
> 
> Dom suggested that we indicate whether this property is permanent or
> not, but I'd rather not do that.  There are cases where an application
> can know that this status is permanent (such as when the track comes
> from gUM, and a tainted canvas cannot be un-tainted), but I think that
> the advantages are fairly marginal.

I guess the reason I was suggesting this was that it now means that,
unless you have explicit control on the origins of your
mediastreamtracks, dealing with onisolationchange becomes pretty much
mandatory for any code that uses mediastreamtracks, which is a bit sad;
but it is not a big deal either, and should it prove really a nuisance,
we can look into that later in any case.

> 
> 2. Get the reason for negotiating an isolated RTCPeerConnection right
> 
> Since peerIdentity constrained tracks are the only type of isolated
> track that can actually be sent over the network, these are the only
> type of track that will cause the RTCPeerConnection to request stream
> isolation (and the ALPN tag).
> 
> This means that other types of isolated tracks will not cause the
> session to become isolated.

I hadn't gotten that in the discussion yesterday (was this discussed
after the meeting?)

That seems like it alleviates the concerns I was trying (unsucessfully)
to explain with my "creative canvas with kittens" story :)

> 3. Surface an error when a track stops sending content
> 
> We will not prevent an application from calling addTrack on an
> isolated track.  For the case where the isolated property changes,
> this would prevent an application from preparing a session with tracks
> that are currently isolated.
> 
> Instead, we will provide an event when tracks start sending
> black/silence/null.  I'm thinking that the RTCRtpSender is the right
> place to put this event:
> 
> partial interface RTCRtpSender {
>   attribute EventHandler? onsendnull;
> };
> 
> 
> 4. We need to make a note that metadata is leaked for isolated tracks
> 
> That's an editorial tweak, but it's also a note that we need to be
> careful with stats.
> 
> So far, only audio level concerns me.  More than ever, I'm thinking
> that we need to make audio level a property of a track, not something
> that appears in stats.
> 
> 
> I plan to send pull requests for each of these items to the editors
> over the next few weeks.

This all looks very good, thanks!

Dom

Received on Friday, 23 May 2014 08:29:38 UTC