Re: Rationalizing new/start/end/mute/unmute/enabled/disabled

On 4/9/2013 6:49 AM, Stefan Håkansson LK wrote:
> On 4/9/13 12:26 PM, Robert O'Callahan wrote:
>>
>> Anyway, we don't have to specify ProcessedMediaStream or anything like
>> it right now, but I think it's helpful to have some shared idea of where
>> APIs might go because that informs the decisions we make now. In
>> particular people have been talking about whether and how the source of
>> a track might change, and features like ProcessedMediaStream are
>> relevant to that.
>
> I agree, we don't need to specify this right now, but it is good to 
> have in mind. As this would (presumably) be an extension to 
> MediaStream, it could be a document of its own.
>
> And it also seems that we have a solution for the most urgent "switch 
> source" use-case: Muzak to a legacy end-point (where we can use the 
> web audio api).
>
> My outstanding question is if we should do something about 
> "media-element.captureUntilEnded" now, or if that can also wait.
>

Well, that enables a whole bunch of important use-cases (generally 
having some sort of encoded non-camera/mic as a source is needed, and 
capturing a media element is the most versatile option I believe - could 
be a local file, could be a remote resource, etc).  I share roc's 
concern about using a canvas as not being performant for realtime video 
(and not dealing with tracks well, clumsy, etc). From the basic 
telephony "Please leave a message" on up, there is use for this.

An alternative would be a getUserMedia() option (constraint I assume) 
that actually generated the stream from a supplied URL instead of asking 
the user.  This would lose a few options which are possible if it's run 
through a <video> element (such as I suspect generating video from a 
canvas you're drawing into - think whiteboards).

So I think it's extremely useful, but there's one issue:

There may be a security issue with captureStreamUntilEnded() with 
cross-origin issues...  if you can put it in a MediaStream, even if the 
origin taints it to where the app can't then get to it directly, it 
could run it through a loopback pair of PeerConnections to "sanitize" 
it.  Hmmm....  Roc, any ideas?

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Sunday, 14 April 2013 06:15:22 UTC