Re: Comment to issues in MediaStream Capture Scenarios: Preview a stream

On 12/15/2011 07:10 PM, Travis Leithead wrote:
>> -----Original Message----- From: Timothy B. Terriberry
>> [mailto:tterriberry@mozilla.com]
>>
>>> [bryan] I agree, I cannot think of a typical use case that would
>>> require 1:N association.
>>
>> I can think of several. Suppose you want to take a local capture
>> stream and a) send it to a remote PeerConnection, while b)
>> recording it locally and/or c) showing a local preview. To say
>> nothing of wanting to send it simultaneously to two or more remote
>> PeerConnections (for small conferences that don't want to use a
>> dedicated mixer).
>
> Presumably you don't need to call "createObjectURL" in order to send
> the MediaStream out via a PeerConnection, right? Depending on what we
> spec, we might not need to createObjectURL in order to record
> either.
>
> Can you think of a scenario that would require multiple "previews"?
> In other words, for createObjectURL, should the resultant URL be
> one-time-use for a video/audio tag, or multi-use? If multi-use, then
> why?

I think it is clear that there are several usages that motivate a 1:N 
relation between the source and the sinks of a MediaStream.

Some of the sink types require "createObjectURL", others don't, but IMO 
the question of whether the URL created by "createObjectURL" is 
re-usable or not is a separate question (and in fact debated in WebApps 
right now, started here 
<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1499.html>). 
If it is not re-usable you could do several "createObjectURL" on the 
same MediaStream (but it would be more convenient if it was re-usable).

And I don't see a reason why we should stop the app developer from using 
several pre-views if she/he wishes to.
>
>

Received on Saturday, 17 December 2011 07:41:19 UTC