Hi Rob! Cool cool, i'm looking through this now. What i've implemented to work with changing source files (since i do have that, quite often) is a simple check that i can run every time i need the index. If it needs to update it, I run a thread reponsible for building or appending to indexes.
for the Google video, how about this one: http://video.google.com/videoplay?docid=5547481422995115331&q=duration%3Along&total=567753&start=0&num=10&so=0&type=search&plindex=4 "Zeitgeist", almost 2 hours long. I'll drop it down here and see what happens. Rob Schoenaker wrote: > Niels, > > If you can read C#, find the source file attached. I suppose you can > work this out :-) > > The class of interest is FLVAnalyzerProgress. > > The FLVReader.close() and FLVReader.analyzeKeyFrames() have been > modified to fit this analyzer class. > > When the keyframes are analyzer, I serialize them to a binary file. His > way, I can load them from this file too. The only problem is that the > data is not aware of any changes to the source video. This needs to be > worked out stil.. > > Apart from this, I used local variables instead of the functions and > properties provided by the stream classes. The stream classes proved to > be slowing this down. Although the delay is only about 10%, I decided to > add the locals to get more speed. > > Keep in mind that this is code from the 0.62 trunk! > > > For the movie from Google Video, please give me a link to download it > from. I can then test this agains this version and see howlong it takes > to generate the key-frames file. > > I hope this clarifies my modifications. If not, please do not hesitate > to reply! :-) > > /Rob > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Niels Joubert > Sent: donderdag 9 augustus 2007 23:20 > To: [email protected] > Subject: Re: [Red5] Long Audio-Only Flv Playback - BUGFIX UNDER WAY > > Hello Rob! > > That sounds interesting. As part of my scheme I have only one indexing > object per FLV on disk, so if multiple people are accessing the same > stream, each one will have an FLV reader, but each of those readers will > > refer to the same index object. Mine doesn't queue any requests though. > > It seems that to get the full duration of a video clip, you need to > build the index, since FLV files per definition does not have a > "duration" header, only a duration metadata flag, whihch is never > guaranteed to be set. This is why I stepped away from an > "index-if-neccesary" scheme, but rather always build it in the > background. Did you get around this? Could you explain your scheme a bit > > more? My code will be in Jira sometime soon, so you can take a look at > it then. > > Altough i'd like to share the video i'm using, it is unfortunately not > content i'm in a position to release, so i'm going to have to direct you > > to a different source. We can both grab a movie of Google Video. > > Can you say a bit more of the optimization you've done for the C# > version? I haven't touched any of the live-streaming code, only working > with the VOD type things, touching the readers, files and > PlaylistSubscriber, etc. > > Rob Schoenaker wrote: > >> Niels, >> >> I have implemented a queuing mechanism around this that generates >> keyframe-data when requested. As soon as multiple requests for the >> > same > >> file are made, they queue up and wait for the master-analyzer to >> > finish. > >> Also, since I did some substantial optimization on the C# version of >> > the > >> code. I would like to test with you big 4 hour video file, if >> > possible. > >> This may aid in getting more analyzer-performance on your end, or >> > mine. > >> So, if possible, please provide a download link for the 4 hour video >> file. >> >> Cheers, >> >> Rob Schoenaker >> >> >> _______________________________________________ >> 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
