In the current trunk version (which should be in 0.6r2 as well) the file is loaded by chunks into a small buffer as each section is needed. Currently however, red5 does scan the entire file before it begins playing causing it to request a lot of page faults to the OS. Most OSes will respond with an address to a new memory location rather than using the old one when memory is requested that fast. However, the memory is still released though back to the OS after each chunk is read. Most unix system (and perhaps windows I'm not sure) will keep the memory in an inactive buffer even after the memory is released by the application and has become available again. In this case programs such as top will not list the memory as "free" but instead as "inact". Could this be what you are seeing?
--Dan-- On Feb 27, 2007, at 8:48 AM, Nathan P. Johansen wrote: > Hi Everyone, > > I'm curious - I have FLV files that are about 350 MB in size, the > playing > time is about 90 minutes. When I connect to Red5 and start > streaming the > file, there is about a 30 second delay, and watching the memory on my > system (Debian - using the "vmstat 5" command) it's obvious that the > entire file is being read into memory. Once it's there, playback, > seeking, and so forth works fine - it's fast and responsive. > However when > I disconnect, the file remains in memory. > > My question: is it necessary for the entire file to be loaded into > memory? > Why does it not instead try to read the data as it is needed from > disk? > With about 2 GB of RAM, looking at more than three such similar files > quickly sucks up all the available memory and causes the thing to die. > > I'm still using the 0.5 version - however on my Windows machine > testing > the 0.6rc2 version, it appears that the same thing is happening. > > Nathan > > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
