Re: MediaStream Recording : record() method

>> Again, the media recorder is going to buffer until it runs out of space.
> Do you mean if the MediaRecoder implementation ignores the timeslice?  If
the MediaRecorder implementation is honoring the timeslice argument, why
would it buffer continuously?

The blobs returned will need to be stored somewhere. They either go to
memory - the UA will probably enforce a quota there - or they go to disk,
in which case they go against the Storage quota. Either way, if the blobs
are not processed timely, that quota will be exceeded at some point, and
MediaRecorder will need to stop recording.

Yes, _if_ you process each blob exactly at the timeslice it arrives, you
are fine. But there's no way we can guarantee an app will do that. Neither
can you for your app - if there's network congestion, data will pile up.


 - rachel



On Wed, Aug 28, 2013 at 2:01 PM, Mandyam, Giridhar <mandyam@quicinc.com>wrote:

> Hi Martin,
> Thanks for the response, but I am still not understanding the point being
> made.
>
> Maybe I should state in a different manner the  original point which I was
> hoping to make:  in absence of a TCP-based PC the most suitable option to
> meet the RT speech recognition use case was timesliced data being returing
> from record().   This has been discussed before on this list - see
> http://lists.w3.org/Archives/Public/public-media-capture/2012Nov/0076.html
> .
>
> > Harald's point was that a real-time application will observe the delays
> resulting from packet loss and adjust what it sends accordingly.
>
> If the argument is that the existing UDP-based PC is sufficient to achieve
> loss-resilience for RT speech based on app-layer codec rate adaptation, I
> am not completely sold.  RT-speech, where data rates can be relatively low
> (e.g. ~4 kbps for EVRC-B encoding, if supported by the platform), may not
> have a lot of room to go much lower.    But I will defer to you on this
> topic, as your experience w/Skype may have proven otherwise.
>
> >  A straight media recorder might just let the buffers back up a little
> more.
>
> > Again, the media recorder is going to buffer until it runs out of space.
>
> Do you mean if the MediaRecoder implementation ignores the timeslice?  If
> the MediaRecorder implementation is honoring the timeslice argument, why
> would it buffer continuously?
>
> -Giri
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Wednesday, August 28, 2013 1:38 PM
> To: Mandyam, Giridhar
> Cc: Harald Alvestrand; public-media-capture@w3.org
> Subject: Re: MediaStream Recording : record() method
>
> On 28 August 2013 13:28, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> > I think it depends on what you consider “lossless”, or at least
> > sufficiently high quality for RT speech recognition (which was the
> > main use case for time-slicing on the record method).
>
> Harald's point was that a real-time application will observe the delays
> resulting from packet loss and adjust what it sends accordingly.  A
> straight media recorder might just let the buffers back up a little more.
>  One optimizes for latency, the other doesn't.
>
> It gets more interesting when you get a routing flap or some other
> less-time-constrained problem.  That's when you might see a real-time
> implementation crank the send rate to zero.  Again, the media recorder is
> going to buffer until it runs out of space.
>
> Both scenarios are probably completely workable for an application that
> doesn't regard latency as paramount, but they will have different
> characteristics that - in some cases - will surface.  Not all abstractions
> are equal, unfortunately.
>