W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2011

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

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sat, 17 Dec 2011 08:40:37 +0100
Message-ID: <4EEC4775.8010806@ericsson.com>
To: public-media-capture@w3.org
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 
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:08 UTC