Re: Mozilla/Cisco API Proposal

On Fri, 15 Jul 2011, Cullen Jennings wrote:
>
> I understand your position presentation are better not done as video and 
> though I agree with you, the practical reality is that power points with 
> animation are widely used and the video becomes about the only way to 
> deal with them.

I don't think this is the case on the Web.


> When people say presentation, they are often talking about application 
> and desktop sharing.

UAs are naturally free to support desktop sharing as a possible camera 
source, but then the UA would know that the video is the desktop, and the 
page would not need to give any hints on the matter.


> The way that works best is rfc4733. The short summary of this is it 
> sends it over the RTP stream and sets up separate codec for DTMF. It's 
> not really a codec in the traditional sense, it just sends a RTP pack 
> that indicates the user pressed a "7" or whatever.

How does this audio codec get negotiated? Does it get its own audio 
stream, or is there a way to negotiate one audio stream with multiple 
active codecs? The RFC wasn't very clear to me on this matter.


> >> 2) Battery life. My iphone might be capable of doing awesome H.265 HD 
> >> video but with a battery life of 45 minutes due to no hardware 
> >> acceleration. However, with h.264 in the right mode it might get 10x 
> >> that time. And if I was in an application where HD provided no value, 
> >> I might want to use smaller resolution. So the browsers might always 
> >> want to provide the "best" it can but "best" gets more complicated 
> >> when trading off battery life. I used 264/265 in this example but you 
> >> will have the same problem with VP8/VP9. Of course the default simple 
> >> examples should make it so a user does not have to think about this. 
> >> And the API should be designed such that people don't override with 
> >> lame defaults. But I think advanced applications need to have some 
> >> influence over the definition of "best".
> > 
> > Agreed, but that's the kind of thing we find out after deploying the 
> > first revision.
> 
> Understand your overall point but this is something we have already 
> learned given what is already deployed.

How can we have learnt how this works on the Web? It's not been available 
on the Web!

Lessons learnt from desktop/native apps do not automatically transfer to 
the Web. The Web is a rather peculiar environment with quite different 
constraints. (For example, the barrier to entry in the Web development 
world is much lower, so there are far more developers who aren't experts.)


> Totally agree. That's way it's important to make sure we have the right 
> extensibility points in to start with. I'm not saying we need to think 
> of every way that best might ever be defined on day one, but we do need 
> to make sure there is a clear point where we can add things we learn in 
> the future.

Agreed. If there are any places that are lacking extension points, please 
do bring them up.


> > To allow us to move fast and iterate, we have to start with the bare 
> > minimum, and then add what people want. Almost by definition, advanced 
> > applications aren't going to be completely catered for in our first 
> > attempt. :-)
> 
> Sure, I understand, I also understand how fast users bother to move to 
> new browsers. We need to catch the right balance.

People are upgrading faster and faster these days. Chrome, for instance, 
transitions about 90% of its user base to a new version within about a 
month of the new version being released.


> >> There's two layers of signaling going on here. The ICE and the SDP. 
> >> If both sides simultaneously send an offer to the other side, I don't 
> >> think ICE sorts out what happens next.
> > 
> > As far as I can tell, this is an ICE role conflict, which ICE handles 
> > fine. If it's not, could you elaborate on what the difference is 
> > between the case you are concerned about and an ICE role conflict? 
> > (Ideally with examples, so that I can compare it to what I thought the 
> > spec said.)
> 
> The ICE spec is very confusing - not a great spec. My original comment 
> was about if we needed explicit open() or listen() and I'm gong to go 
> rethink that now that I understand the event model better. But to 
> explain a bit about 1 to many with ICE ...
> 
> Say A wants to connect to B and C. Lets say A was not behind any NAT, 
> has single IP, and no TURN sever. So all A gets is a single local port 
> as it's only candidate. A gathers candidates and then starts ICE 
> connections with B and C using the same candidates it gather. B and C 
> both do the usual ICE thing and A is connected to both B and C.  A would 
> end up using the same local port to talk to B and C.

Why? When A gathers its candidates for B and C it wouldn't [have to] use 
the same local port. Those are two different ICE agents.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 25 July 2011 21:24:16 UTC