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

Re: Communicating memory pressure in mediastream recording

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 30 Jul 2013 11:39:11 +1200
Message-ID: <CAOp6jLZgL9arAbby4ZqOC_OwUQ_F_NgJaRT0Lzx=b7-ctKs7Nw@mail.gmail.com>
To: Greg Billock <gbillock@google.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Tue, Jul 30, 2013 at 4:34 AM, Greg Billock <gbillock@google.com> wrote:

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

Can you give a specific example of a use-case for this?

In Gecko, data accumulated by the recorder is initially kept in memory.
Once it exceeds a certain size (1MB) we transfer it to a file. So, Blobs
below the threshold are memory-backed, Blobs above the threshold are
file-backed. It would be possible for an application to exhaust memory by
using a small timeslice and accumulating all the Blobs in a list, but why
would an application need to do that? AFAIK the only reason to use a small
timeslice is if you're going to stream the recorded data to a file or
across the network.

Even if an application does need to do that, I'd much rather handle the
low-memory situation by having Gecko transparently move Blob contents from
memory to files than by asking the Web application to handle it. I have low
confidence Web developers would bother handling low memory, or would be
able to handle it robustly if they did try.

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
Received on Monday, 29 July 2013 23:39:38 UTC

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