W3C home > Mailing lists > Public > public-media-capture@w3.org > July 2013

Re: Communicating memory pressure in mediastream recording

From: Greg Billock <gbillock@google.com>
Date: Mon, 29 Jul 2013 14:41:37 -0700
Message-ID: <CAAxVY9f+fr8gEAk-m4CNULPkOqoYHzjcsqeROOU3PLm2q65hnQ@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
We'll probably have more useful to say about error states as we start the
implementation, but there is an onwarning event handler in the spec. That
may be a better match for messages like this, but my inclination would be
to include it in the error channel -- if it's something the app can respond
to, it's more of an emergency.


On Mon, Jul 29, 2013 at 9:58 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  Greg,****
>
> I’ve thought for a while that Low_memory would be more useful than
> out_of_memory.  A “you’re totally hosed, dude” message is really not as
> useful as “you’re gonna be hosed if you don’t do something soon”.   One
> question is whether Low_Memory should be an error event or if we need a
> separate class of warning events  (and, if so, what are the other warnings?)
> ****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> *From:* Greg Billock [mailto:gbillock@google.com]
> *Sent:* Monday, July 29, 2013 12:34 PM
> *To:* public-media-capture@w3.org
> *Subject:* Communicating memory pressure in mediastream recording****
>
> ** **
>
> Another implementation issue that may be useful to surface in the API:****
>
> ** **
>
> In the record(timeslice) case, the implementation will probably not want
> to incur the latency penalty of writing each intermediate block to disk
> before creating the blob handle. This means some coordination is required
> to make sure the app doesn't let too much in-memory content accumulate.
> (The no-timeslice overload shouldn't have this weakness.)****
>
> ** **
>
> There's already a channel for communicating this kind of pressure with the
> onerror/onwarning event handlers. The ondataavailable event is the trigger
> for it, and there's already an OUT_OF_MEMORY error that can be used for
> failure if the implementation has to start dropping slices or take some
> other remedy. Should there be a LOW_MEMORY warning enum value to indicate
> to the app that if it's waiting around to delete intermediate memory it
> should do so immediately?****
>
> ** **
>
> To reinforce this coordination, would it be helpful to have
> record(timeslice) also take an onerror handler to help make sure app
> developers are accounting for the increased coordination effort they'll
> need to have to use the API successfully?****
>
> ** **
>
> -Greg****
>
> ** **
>
> ** **
>
Received on Monday, 29 July 2013 21:42:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC