- From: Tran, Dzung D <dzung.d.tran@intel.com>
- Date: Wed, 16 Dec 2009 11:10:35 -0800
- To: Ian Hickson <ian@hixie.ch>, Andrei Popescu <andreip@google.com>
- CC: Anne van Kesteren <annevk@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Ben Murdoch <benm@google.com>
Isn't H.263 the most commonly used format for video conferencing/chat? I have no idea about any patent issue with this codec. Thanks Dzung Tran, -----Original Message----- From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Ian Hickson Sent: Wednesday, December 16, 2009 09:47 AM To: Andrei Popescu Cc: Anne van Kesteren; public-device-apis@w3.org; Ben Murdoch Subject: Re: <device> proposal (for video conferencing, etc) On Wed, 16 Dec 2009, Andrei Popescu wrote: > >> > If I understand the example correctly, the video element will show > >> > the output of the user's camera (i.e. act as an embedded camera > >> > viewport). To be able to implement video chat, we also need a way > >> > to see the remote party, so we need a way to send the Stream over > >> > to some server. I think we should specify the mechanism for doing > >> > that (e.g. WebSockets::send(Stream stream)). > >> > >> I believe this is the plan yes, if the general proposal can be made > >> to work. > > > > Indeed. The problem is that this requires a chosen codec, and we don't > > have one. That's why I stopped where I did. > > Perhaps I am missing something, but this requirement isn't entirely > obvious to me :) Why do we need to agree on a codec any more than we > needed for the <video> tag? We need to for <video> also. However, in this case we need to even more, because otherwise there's no guarantee that a user with one browser could chat to a user with another browser, which makes the whole exercise pointless. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 16 December 2009 19:11:24 UTC