- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Tue, 3 Sep 2013 19:31:03 +0000
- To: Rachel Blum <groby@google.com>
- CC: Greg Billock <gbillock@google.com>, "Mandyam, Giridhar" <mandyam@quicinc.com>, Robert O'Callahan <robert@ocallahan.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810749EC@GENSJZMBX02.msg.int.genesyslab.com>
By the way, the issue of letting the UA provide more data than the time slice has come up before, in discussing video capture. As I recall, the argument was that in some cases it may be much more efficient for the UA to round up to some convenient size (the nearest frame boundary?). Does anyone remember more on this issue, or object to Greg's wording? I interpret it to mean that the UA can exceed the timeslice for reasons other than setting a minimum buffer size. - Jim P.S. Rounding up isn't necessary with the sort of audio codecs that spec rec systems use, but it's also not an issue if they get a bit more data than they asked for, since the underlying recognition algorithm runs on the fully concatenated data. 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:31:27 UTC