Re: Constraints and MediaRecorder

Thought on how to dynamical sense what frequency ranges work? seems hard to differentiate from a quiet room.

On the video, yes, agree. There is a whole protocol, RTCP, to provide stats back on the RTP - the STUN also provides ongoing connectivity information. The browser exposes that information up the the application via the stats interface. 



On Feb 3, 2014, at 3:33 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> 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

Received on Monday, 3 February 2014 22:39:34 UTC