Hello Adam and other Red5 Users
This is a known issues with Red5's IO capability, and I am currently
working on a patch that will fix all these issues.
Red5 builds index files that represents the keyframes and corresponding
byte-offsets of the media you are playing. You can open up the index
files with a XML editor and see this. The problem with this approach is
that XML is ridiculously slow for long lists of data (we're talking
about 10 000 + entries) and Red5 keeps all these lists in memory,
synchronizing it with the disk-based version.
When you open a file for the first time, Red5 runs through the whole
file, finding keyframes (or, in the case of music, EVERY frame), and
corresponding byte offsets, making a list in memory of this, and finally
writing it to disk.
When you open a file that has an index, on your first seek, Red5 loads
the whole XML file into memory (For a 4 hour video, anything between 3
and 10 MB of XML) before pushing the seek - which it does by seeking
linearly, from the start of the file, to find the closes keyframe. This
means that each file being opened can take 10MB of memory easily if
you're using big video files.
Unfortunately this is a slowdown and causes memory bloat with big files.
I have patched Red5 to use a fast binary-based disk index file, that
keeps as little information as possible in memory, and does smarter
seeking. I routinely throw full-length movies in 1080p at it and it
happily spins through them. This patch is almost ready for inclusion in
Red5, at the moment i'm working on making it multi-threaded, so that
there's no wait when a file loads, and the index gets built in the
background.
Hopefully this will be integrated soon, but at this point in time, your
best bet is to connect, and wait until the index file is built (it keeps
building even if the client gets disconnected) and connect again if the
index file is done building. Look at the changing filesize on disk of
the index to see when it's done.
good luck, we'll have this part of Red5 blazing soon enough! My initial
tests show that I can open 4000 files at the same time with a memory
overhead of about 40Mb.
Adam wrote:
> Oh, and I tested with Red5 pulled out of the Trunk today,
> so I should be using the latest version here. It's failing
> on my Mac, and also on the Windows machine (though probably
> not with the trunk release over there).
>
> Thanks again,
>
> Adam......
>
> On Wed, Aug 08, 2007 at 04:10:20PM +0100, Adam wrote:
>
>> So nearing a functionally complete version of my software,
>> and actually using it for it's intended purpose a little
>> rather than doing quick tests, we've come across a large
>> problem. Or at least a problem with large files.
>>
>> Playing an audio-only .flv file works well, until the
>> file is more than about 45 minutes long. Then it really
>> slows things down during some initializating phase before
>> reporting "Closing RTMPMinaConnection from 127.0.0.1:49372
>> to localhost (in: 3427, out: 3262) due to too much
>> inactivity (1186585160652)"
>>
>> Here's a stripped down program that shows my problem here:
>> -------------------------------------------------------------------
>> ncStatus=function(info){
>> trace("Net Connection Status Change: Level"+info.level+"
>> Code:"+info.code);
>> if(info.code=="NetConnection.Connect.Success"){
>> trace("Connection Complete - playing");
>> _root.aud_ns.play("test.flv");
>> }
>> }
>>
>> trace("Createing New Netstream");
>> _root.nc = new NetConnection();
>> _root.nc.onStatus = ncStatus;
>> _root.nc.connect("rtmp://localhost/test");
>> _root.aud_ns = new NetStream(_root.nc);
>> -------------------------------------------------------------------
>>
>> Nothing too complicated there as you can see. When the
>> webapps/test/test.flv file is less than 30 minutes long,
>> it works without trouble. When it's greater than 60 minutes
>> it consistantly fails with that error.
>>
>> Is this a known bug? Should I put in a bug report? Anyone
>> got any clues on any workarounds I might be able to use?
>> I'm supposed to be demoing this project in about 3 weeks.
>> Eeep.
>>
>> Thanks for your help,
>>
>> Adam............
>>
>
> _______________________________________________
> 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
