- 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
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 UTC