This is insane, I think this may solve some of our problems aswell with
our larger videos which are over 200MB each.
Niels Joubert wrote:
> 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
>
>
_______________________________________________
Red5 mailing list
[email protected]
http://osflash.org/mailman/listinfo/red5_osflash.org
