
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. `._.-(,_..'--(,_..'`-.;.'