Yes, that's fine. Platform-specific limits make sense. I just wanted to point out that speech rec was one of the main motivations for the recording API. PeerConnection won't work (according to Nuance). Question: if we decide to add the concept of 'warnings' (as opposed to errors), should the UA raise a warning if the app specifies a value outside the platform-specific limits? - Jim From: Rachel Blum [mailto:groby@google.com] Sent: Tuesday, September 03, 2013 2:59 PM To: Jim Barnett Cc: Greg Billock; Mandyam, Giridhar; Robert O'Callahan; public-media-capture@w3.org Subject: Re: [Marketing Mail] Re: MediaStream Recording : record() method On Tue, Sep 3, 2013 at 11:46 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote: however dropped packets are a significant problem. So strict real-time is not a requirement for speech rec, but lossless good-enough-for-humans time is. The spec currently already precludes dropped packets due to resource exhaustion (indirectly), since exceeding any platform-specific limits MUST signal a fatal error. So there's no dropping, only end of recording. I take it that Greg's edit is then OK with you? (recap'd below) "3. If the timeSlice argument has been provided, then once at least timeSlice milliseconds of data have been collected, or some minimum time slice imposed by the user agent, whichever is greater, raise a dataavailable event containing the Blob of collected data, and start gathering a new Blob of data. Otherwise (if timeSlice has not been provided), continue gathering data into the original Blob. Callers should not rely on exactness of the timeSlice value, especially if the timeSlice value is small. Callers should consider timeSlice as a minimum value."
Received on Tuesday, 3 September 2013 19:03:24 UTC