W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

RE: Mozilla/Cisco API Proposal

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 19 Jul 2011 08:02:54 +0200
To: Ian Hickson <ian@hixie.ch>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, "public-audio@w3.org" <public-audio@w3.org>
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D616C3C4567F@ESESSCMS0362.eemea.ericsson.se>

>-----Original Message-----
>From: Ian Hickson [mailto:ian@hixie.ch] 
>Sent: den 18 juli 2011 20:46
>To: Stefan Håkansson LK
>Cc: public-webrtc@w3.org; public-audio@w3.org
>Subject: Re: Mozilla/Cisco API Proposal
>On Mon, 18 Jul 2011, Stefan Håkansson LK wrote:
>> In
>> rements/> there is a use case that uses two cameras: Hockey game 
>> viewer. There one camera is used to show the game, the other 
>a view of 
>> a person attending the match (and participating in an on-line 
>> discussion about the game).
>> I guess that if the web app gets access to both cameras switching 
>> views would be simple to implement. You could be lazy and transmit 
>> both videos all the time but select which one is displayed in the 
>> video element, or you could enable/disable tracks or add/remove 
>> streams at the sending side if you like to save transmission.
>The current API already supports this -- you'd just get the 
>two camera using getUserMedia(), add both streams, and then 
>mute the one you don't want to send.
I agree. This was kind of the point I was trying to make.
>We may want to consider a way to merge MediaStream objects 
>into one (currently there's only the ability to fork), so that 
>you could just send one stream and dynamically pick one or the 
>other. But it seems if we do that we'd probably also want to 
>be able to do fades and other transitions for the video, and 
>of course we'd probably want this to hook right into the audio 
>API. It's unfortunate that this area is split across multiple 
>working groups at the W3C.
I agree to that we have a challenge in coordinating things between the WGs.

A couple of other reqs (the ones about being able to spatialize and mix audio streams and sound objects - F13 & F15) are really in the Audio WG space.

It would be a real shame if the APIs end up incompatible.

Received on Tuesday, 19 July 2011 06:03:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:20 UTC