- From: Timothy B. Terriberry <tterriberry@mozilla.com>
- Date: Thu, 06 Oct 2011 06:18:26 -0700
- CC: public-webrtc@w3.org
> This sounds like a good idea. But would not the natural time to add > "hints" be at getUserMedia time? I think the answer is "yes", but there's already the "JS Object" that Anant was proposing in his change. Though I think the idea there was to tell the browser which type of media (audio, video, or both) you are requesting, there's no reason browsers couldn't interpret more properties there later on. > My reasoning being that the "hints" (as you say below) are in 99.9% of > the time set once and never changed, and can in addition have an effect > already earlier in the chain (before the codec). E.g. if a hint is "fast Also, on the converse side, one might want to specify hints when sending a MediaStream that did not originate with getUserMedia() (e.g., one that came from an <audio> tag, etc.). That is, in fact, exactly where you would want to specify audioApplication: General instead of audioApplication: VOIP. The only part of the audio chain that I can think of that you might want to disable on the getUserMedia() side is the AEC, and I'm not sure exposing that knob is a good idea (it may be okay if you know the user is using headphones, but it's the browser, not the JS, that has the best chance of figuring that out). > moving content" the camera might be set up to record with a higher frame > rate - the effect would be visible in a view finder even if the > MediaStream is never transported off the device using a PeerConnection. I'm not sure if "hints" are the best approach to specifying things like framerate. An API to query capabilities and make specific requests (with feedback to tell you didn't get what you asked for) may be better (and would certainly make folks like Kaufman happy), but one step at a time. Also, keep in mind that many consumer-grade webcams will simply lie about things like this (they tell you you're getting 30 fps, but the frame actually only changes maybe 4 times a second).
Received on Thursday, 6 October 2011 13:19:03 UTC