Re: [Marketing Mail] Re: MediaStream Recording : record() method

On 09/03/2013 09:31 PM, Jim Barnett wrote:
>
> 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.
>

I think greg's wording looks good. Depending on implementation methods, 
there may be all sorts of reasons why the time slice is hard to obey 
exactly (for instance, if there's a buffer being filled by the 
high-priority capture process and a low priority thread picking data out 
of it that is slow in starting, it may want to take everything that's in 
the buffer instead of finding the point in the buffer corresponding to 
the timeslice-exact timestamp).

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