W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2012

Re: recording proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sun, 28 Oct 2012 09:36:09 +0100
Message-ID: <508CEE79.6080604@alvestrand.no>
To: public-media-capture@w3.org
On 10/26/2012 09:03 PM, Josh Soref wrote:
> Harald wrote:
>> Garbage collection doesn't collect memory that you have explicit
>> references to, does it?
> It doesn't.
>> At 2 Mbits/sec, 0.4 Mbytes/sec, it would probably take you a few minutes
>> to run out of memory (~5 hours for 8G of RAM, actually, unless I slipped
>> a decimal).
>> That's completely OK with me. You asked for it, you got it.
> Assuming my math isn't terrible, this is 1.4GB/hr.
> I'd like to point out that many systems use 32bit processes in which case the entire usable application address space is 2gb (that includes the app and its overhead).
> Your UA+Libraries+application are probably going to consume ~100mb, on top of the first hour of recording (1hr * 1.4GB/hr), which means that there's probably another .5GB available, rounding that gives you perhaps another 20minutes [1hr * (1/(1.4 [GB/hr] / .5 [GB] ~= 1.5/.5) ~= 1/3)].
> That means you have 80minutes, which is unfortunate if you're trying to deal with a 90 minute conference call (which conveniently is the length of the MC TF calls).
> Note that actually running a web browser in 64bit world tends to cause it to waste more memory (because the pointer size generally doubles, and browsers use *lots* of pointers), so even if a mobile device could use 64 bit memory blobs, the UA wouldn't want to (it's better off using multiple processes).
Yep. My point (which was made a bit facetiously) was that if you want to 
record multiple minutes of video, you'd better set up a mechanism to 
write the stuff to some other storage while recording; for recording 
short snippets (video greetings), recording to memory should be fine, 
people don't need to bother with files.

> I'm sorry for the delay, I've been worrying about other things.
No problem!
Received on Sunday, 28 October 2012 08:36:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:37 UTC