- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 28 Oct 2012 09:36:09 +0100
- 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