- 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>
>-----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 >> ><http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requi >> 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. Stefan
Received on Tuesday, 19 July 2011 06:03:22 UTC