- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 04 Feb 2014 06:43:00 +0100
- To: public-media-capture@w3.org
On 02/03/2014 08:55 PM, Jan-Ivar Bruaroey wrote: > On 2/3/14 2:35 PM, Harald Alvestrand wrote: >> On 02/03/2014 06:32 PM, Martin Thomson wrote: >>> These are all fine, but this offers little material support for the >>> use of constraints in this specific use case. Is there anything wrong >>> with: >>> >>> app: get me a 96kHz recorder >>> browser: can't do that >>> >>> Because that's what is being suggested. >> It seems to me more complex to do: >> >> app: get me a 96khz recorder >> browser: can't do that >> app: get me a 80khz recorder >> browser: can't do that >> app: get me a 48khz recorder >> browser: can't do that >> app: get me a 44.1khz recorder >> browser: ok, here's one >> >> than to do >> >> app: get me a recorder absolutely above 40 khz, prefer one above 80 khz >> browser: ok, here's an 88.2khz recorder > > The first one is simpler because the second one is a new language. But since we already have this language in GUM, it's no longer a new language. (I may have been too subtle. In the probing approach, you ended up with a 44.1 kHz recorder because that's what the application knew how to probe for. In the "ranges of options" approach, you ended up with an 88.2 kHz recorder because the application did *not* probe for specific values.)
Received on Tuesday, 4 February 2014 05:43:42 UTC