Hi Martin, Looks like great stuff. I did notice though in a quick scan of your code that you load from a file with a .kfcache extension and write to a file with a .Red5cache extension. Also might be beneficial to add a check in the loadKeyFramesCache method to do a comparison of the lastModifiedTime of the cache file and the flv file and if the flv is newer delete the cache so it can be re-created.
Thanks again for the code. --Dan-- On Nov 16, 2006, at 4:08 AM, Martin Schipper wrote: > Hi guys, > > First of all I like to say I don't read all the posts here. So > maybe someone has already posted a patch... If not; here is one :) > > Earlier I posted a problem I encountered while serving 'large' FLV > files and files with the same filenames in different paths. > The problem is the cache mechanism and the new ByteBuffer > implementation. As I wrote then, maybe it's just not a good idea to > 'cache' the whole FLV in heap mem... maybe it's an idea to leave > the caching to the OS (unless it's a small and often played file, > like a banner ;)). > > To fix the problems I patched the FLV and FLVReader class so it > doesn't cache anymore and it doesn't 'allocate' the MINA > ByteBuffer. Furthermore I added a file-based caching mechanism for > the KeyFrame Meta-info (FLVReader) so it doesn't 'scan' the whole > file every time. > > The patch is tested by playing a 300MB FLV via a bandwidth capped > NFS share, it plays well and it uses only 7MB from the 16MB heap (- > Xmx=32m and -Xms=16m). > > Since you guys did all the great work I whould like to share the > patch and hope you can use it (or at least the idea). > > Greetz, > > Martin Schipper > > p.s. I patched upon SVN version 1535 > p.s.2 Maybe attachments don't work in this list so I'll also put > them online at: http://www.dbcorp.nl/red5/ _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
