[RTW] List is now open
Ian Hickson
ian at hixie.ch
Mon Oct 11 21:11:54 CEST 2010
On Sun, 10 Oct 2010, Justin Uberti wrote:
>
> My idea is that we will tie these various pieces together like a filter
> chain, i.e.
>
> <device> -> [encoder] -> [transport] -> [decoder] -> <video>
This is basically what's in the HTML spec today:
On the sending side:
<device> is <device>
[encoder] is a Stream object
[transport] is a PeerConnection object
On the receiving side:
[transport] is a PeerConnection object
[decoder] is a Stream object's .url attribute
<video> is a <video>
The details are abstracted out a lot at this point; the idea is that
future versions of the API can add specific knobs and dials to allow
authors to control what they want to change; we can decide what to expose
based on what people most want. This dramatically limits the complexity of
what we have to implement, and makes it more likely we'll get interop
sooner. However, I need to do some work on this spec to merge in the ideas
from some of Justin's work, so this may change a bit. What will certainly
change is the way the low-bandwidth channel maintained by the script is
interfaced with on the PeerConnection object; I also need to move some of
the Session stuff into the spec, e.g. sending of DTMF tones.
Work still has to happen to define how information is conveyed to the
browser, in particular, what format the browser should expect server
configuration to be in. We also need a spec defining how browsers use
ICE/STUN/etc, e.g. how they identify which PeerConnection object an
incoming connection is related to -- imagine the situation of a script
trying to open two simultaneous connections between the same two browsers.
One thing that might make sense is for me to write a skeleton of what I
imagine the "next layer" would look like (the spec layer that defines the
format of the data that the browsers use to talk over the low-latency
channel, defines how ICE/STUN/relays/etc are used, defines what the
relays are, defines how to do video codec negotiation, defines how to
identify which packets go with which PeerConnection, defines how to
respond to specific API calls in terms of data on the wire, etc), and to
then hand that off to someone who actually knows how that is all to be
defined. Would that make sense?
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the RTC-Web
mailing list