Here's what I put in place for the last modified check on my
installation inside the loadKeyFramesCache method:
File kfCacheFile = new File("/usr/local/
flash/cache/" + file.hashCode() + ".Red5cache");
if (kfCacheFile.isFile() &&
kfCacheFile.canRead()) {
if (file.lastModified() >
kfCacheFile.lastModified()) {
kfCacheFile.delete();
return false;
}
ObjectInputStream in = new
ObjectInputStream(new FileInputStream(kfCacheFile));
I'm going to be testing the code on a live installation today that
regularly does 30-50GB of data transfer per day. Hopefully it may
help out some problems as I've been having the server crash from
running out of heap with caching turned off. My heap was set to about
1G.
Thanks again!
--Dan---
On Nov 17, 2006, at 5:26 AM, Martin Schipper wrote:
Thanks very much Dan,
I didn't test it well... As a matter of fact I changed the file-
extension just before I build a .jar and put it online.. *shame*
Fixed the bug/typo (store duration and fixed file-extension to
'.Red5cache') and for the interested people I put the fixed patch
online at http://www.dbcorp.nl/red5/
Still didn't create a check for the modified date, maybe i'll fix
it later.
Grtz,
Martin
Daniel Daley wrote:
Hi again. I was messing around with your code again and noticed you
are not storing the duration value in the cache. Being that it is
read during the analyzeKeyFrames method, any plays after the cache
has been written will return a 0 value for duration.
Thanks,
--Dan--
On Nov 16, 2006, at 1:00 PM, Daniel Daley wrote:
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
_______________________________________________
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
