Hmm... I think DBR could be used for this purpose very effectively. Here is what I'm thinking about.
You set up a DBR site, and have a file on it called, say, stream.mp3. This file contains the length of sound that is equal to the DBR expiry time. When the DBR time rolls over to the next slot (e.g. one hour), the new file should have already been uploaded. The player has to attempt re-buffering at some fractional interval shorter than the stream segment size. There can be another file, called stream.txt that contains stream information which can contain time index information to establish if the file is the same or not (no point in getting the segment if we already have it). This stream.txt would sort of be redundant with the manifest data, so we could actually insert the stream.mp3 file directly as a CHK without a SSK site manifest. So, now our streaming site has: SSK@<public key>//stream.txt containing: CHK@<hash>,<key>/stream.mp3 + possibly some other information about the stream. The player polls stream.txt once per minute/hour/whatever, and when it detects that the CHK file has changed, it starts buffering the next file. There is no need for tagging these files for deletion because they are just like DBR sites. Once the date rolls on, the pointers to the data are lost (sort of, unless you specifically look for them). This means that the files become inaccessible, and because they are not used/requested, they will be dropped by the nodes when they run out of space. This mean that technology and/or feature wise, there is no need for any additions to the base core network protocol. It will all just work. All that is required is a standard (e.g. as described above) to be addopted and used. If a standard encoding format is to be agreed on, I would suggest Ogg instead of MP3 due to the fact that it has better quality (so I'm told) and there are no legal/licencing/copyright/patent issues over using the encoding format. Obviously, on the network level, the above "protocol" would support any file format as long as the player does. Thoughts? Gordan On Tuesday 29 Jul 2003 20:15, Toad wrote: > It might just be feasible. At some point. In fact, it's a benchmark - > freenet is working if the stream servlets can insert a live 64kbps > stream, and pull it out of a completely unconnected node, without > skipping. > > On Wed, Jul 23, 2003 at 05:18:10PM -0500, David wrote: > > Whatever became of the project to stream audio via Freenet ? > > > > With the integration of the next generation routing into the Freenet > > core, it should be possible to > > acquire better results for audio streams via Freenet or possibly even > > streaming video. > > > > A method would be needed to cache the streaming data ( for continued > > distribution ) for a specific > > amount of time, then discard the data, instead of saving the entire > > stream indefinitely. A method > > of real time file processing would be also needed to take the stream from > > Freenet and process it > > so that the stream content can be readily available for playback through > > the users multimedia > > software. > > > > The Internet contains more than just static files, why should Freenet be > > limited to just static content ? _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
