Re: Constraints and MediaRecorder

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

I gather that roc and martin don't find that argument compelling,
because it's the same argument I've been using for the last ~12 months
whenever we've had one of these "why do we need constraints at all"
debates, so I'd very much like to hear what others think.

>
> On 3 February 2014 06:41, Cullen Jennings <fluffy@iii.ca> wrote:
>> On Feb 2, 2014, at 10:01 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>>
>>> Can you point to a real-life example of an application that would rather just fail than get low-resolution video --- one where that's likely to be a possibility in practice?
>> Sure, I’ve got a great example with an audio constraint that should really be near and dear to you.
>>
>> We build stuff that does ultrasonic identification ( http://en.wikipedia.org/wiki/Ultrasound_Identification ). For this to work, we need to be able to get audio data that is up in say something like the 18KHz range.
>>
>> Today that does not work on Firefox ( bug filed at https://bugzilla.mozilla.org/show_bug.cgi?id=953265 ) because FF seems to cut off everything above 11 KHz. Who knows, this may be an apple bug not FF but perhaps OSX or how OSX is used, I don’t really know. But what I do know is that it works on Chrome but not on FF. If there was a way for me to say I need 20KHz audio, and the browser to say "Sorry, Can’t do that on this device" then I would not need to do what I am inevitably going to go do. Which is, yep, sad but you guessed it, a dialog box that detects if the browser is FF and says "Sorry this application does not work on FF, please use Chrome".
>>
>> Now here is the part that I really really hate about that dialog box. When that bug is is fixed, and every users is using the new version of FF, it will take several years for enterprises to upgrade that application and for the several years, the dialog box will say "Sorry this application does not work on FF, please use Chrome" even though the user has a version of FF that would work just fine.
>>
>> Now there are some sound cards where this application will never work because they can only sample at something much less than 40KHz. Having the browser be able to tell the JS, sorry can’t give you what you need would be a much better user experience in the long run. Knowing the sound card could do 96 KHz sample rates would allow us to do much more interesting stuff no the systems that supported it.
>>
>> So let me be very clear, if we had a way for my JS application to say "I need my audio to have 22 KHz bandwidth" and the browser to say yes or no, as soon as the user had a browser that could do that, the applications would work instead of displaying that evil dialog box for many years.
>>
>> Let me bring it back to an another example with video… most "free" applications don’t provide any direct support where you can talk to a human that will help you. However, there are lots of commercial applications and commercial uses of open source applications that do. Support calls are very expensive both for the company that  receives them and in sense of the users frustration and time. There are many situations where we would rather say "sorry, this is going to be a bad experience so we can’t do it" than to deliver the bad experience and then have it not work and start the expensive support situation. Apple takes the same approach - a large percentage of things in the app store simply will not run on one of the early iPod touch - not because they don’t work - but because they are just sluggish and deliver a bad user experience.
>>
>> So back to video example - many applications we are doing with video we simply want video turned off in the application if we can not deliver HD video. Imagine an screen sharing application that is used to share a word processor documents or a file editor displayed at the resolutions and scales that normal users use. Now imagine that image transformed to video and scaled to QCIF. Obviously none of the fonts are really readable so we would rather the application tell the user it not do it than deliver a result which will be totally unusable all the time.
>>
>> I totally get that some applications just want to do the best they can and let the user decide if it is good enough or not - we build those too. But not all applicaitons want to do that - some want to ensure a minimum quality level of the user experience. The W3C APIs needs to support both types of applications.
>>
>>
>>


-- 
Surveillance is pervasive. Go Dark.

Received on Monday, 3 February 2014 19:35:54 UTC