- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 29 Nov 2010 13:33:59 +0100
On Fri, 26 Nov 2010 19:01:40 +0100, Per-Erik Brodin <per-erik.brodin at ericsson.com> wrote: > A Stream can be treated as an abstract representation of a media stream. > When a Stream is to be transported over a peer-to-peer connection, the > format can be negotiated between the peers. In the current > ConnectionPeer API, such format negotiation would be transparent to the > API. If we would specify a single resolution for video, for example, > that resolution may be to high for some mobile devices to encode in > real-time. A mismatch in supported formats is just one reason why a > peer-to-peer transport may fail, but that doesn't mean that the peers > can't communicate. When relaying through a server you can interoperate > with anything. Via a server, maybe, if the author took care of having a transcoder there. Ideally P2P is without such an intermediary. And although authors can exclude parties now by using proprietary plug-ins, I am not convinced we should make that an intrinsic part of the web. Not finding a codec / simply using VP8 will make that a reality however. > If you are referring to sendFile(file) on ConnectionPeer, the file may > just as well come from the user's hard drive via <input type=file> and > thus it will be up to the application to ensure that whatever is sent to > the other peer is usable there. That is quite a different scenario from exchanging a live media feed. -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 29 November 2010 04:33:59 UTC