On 2/3/14 4:41 PM, Eric Rescorla wrote: > On Mon, Feb 3, 2014 at 11:55 AM, Jan-Ivar Bruaroey <jib@mozilla.com > <mailto:jib@mozilla.com>> 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. > > I prefer: > > > app: get me a 96khz recorder > browser: keep dreaming, here's 48khz, best I can do. > > > I feel like we're just re-fighting the battle about mandatory constraints. > As far as I can tell, there was general consensus to stay with the > existing mandatory/optional constraint structure for gUM. > > I realize that there are a number of people who were in the rough > on that discussion, and are no happier about it here, but unless > there are some arguments that apply in particular to > MediaRecorder and *not* to gUM, then there seems like > a pretty strong consistency argument for using the same style > throughout the specification. This is about using Constrainable in MediaRecorder, which several of us argue is a bad idea, just like it was for RTCPeerConnection, where thankfully it is now gone. We're doing well here and we're talking about MediaRecorder exclusively, so hopefully, this discussion will be equally fruitful. > -Ekr .: Jan-Ivar :.
Received on Monday, 3 February 2014 22:00:37 UTC