Re: Constraints and MediaRecorder

On Tue, Feb 4, 2014 at 3:41 AM, Cullen Jennings <fluffy@iii.ca> wrote:

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

Can you just run the application and have it detect if you're getting the
frequencies you want, and if you're not, then give up? It seems to me
that's the most reliable approach since it not only covers detectable
software limitations but also hardware issues that the browser could not
easily detect.

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

Again, this has to be determined dynamically. For example bad network
conditions could render your video useless. So you will want to detect that
you can't deliver good-enough video and turn it off.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w