W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

Re: Mozilla/Cisco API Proposal

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 12 Jul 2011 03:37:06 +0000 (UTC)
To: Ralph Giles <giles@thaumas.net>
cc: Anant Narayanan <anant@mozilla.com>, public-webrtc@w3.org
Message-ID: <Pine.LNX.4.64.1107120326520.3775@ps20323.dreamhostps.com>
On Mon, 11 Jul 2011, Ralph Giles wrote:
> On 11 July 2011 15:09, Ian Hickson <ian@hixie.ch> wrote:
> > One of the differences is that your proposal allows the author to set 
> > things like the quality of the audio. It's not clear to me what the 
> > use case is for that. Can you elaborate on that?
> 
> Perhaps one example is the sort of thing described by 
> MediaStreamTrackHints in the proposal. The Opus audio codec from the 
> IETF standardization effort can switch between separate "voip" and 
> "audio" coding modes. The script setting up the connection may have 
> context information about which of these are more appropriate for its 
> application. These are qualitative encoding choices, which significant 
> overlap on any quality/bitrate scale.
> 
> Information like that is always going to be codec-specific, so an 
> concrete way of passing ad hoc parameters to the user-agent would find 
> use there.

To me that argues for a way to say "make sure this audio channel supports 
DTMF" and for a way to generate DTMF tones. But I don't think it means we 
need to expose codec information.

As a general rule, I think we should follow a model where authors give the 
browser the constraints and let it work out the implications, rather than 
a model where authors make the low-level decisions. This is because if we 
have the authors making low-level decisions, the browser can't improve 
matters later.

Consider for instance the situation where a Web page says it wants things 
encoded using H.264 1280x768 60fps, non-interlaced, with an audio channel 
that uses the Opus codec and so on. It works beautifully, the author is 
happy, the users are happy.

Ten years later, browsers add support for a new codec which supports 
seamless 3D video and 7.2 surround sound audio, and all computers are 
shipping with lovely 3D webcams running at 8K resolutions that beat the 
quality of today's Red cams, and ultraviolet laser microphones that can 
build a perfect audio representation of the user's surroundings.

The aforementioned Web page gets none of this. It looks like it's ten 
years old. To improve it, the author has to go and update all the codec 
stuff to make it work.

But now consider what happens if instead of saying the codec, the author 
had just said "give me video and give me audio". Ten years later, the 
browsers can all just make 3D work and the site, unmodified, becomes 
qualitatively better without the author having had to do any work at all.

This is why the Web uses a declarative high-level model. It lets us make 
the Web better in the future.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 12 July 2011 03:37:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 12 July 2011 03:37:30 GMT