Re: Constraints and MediaRecorder

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.

Received on Monday, 3 February 2014 14:41:47 UTC