Ian Clarke <ian at freenetproject.org> writes: > How about another set of possible SplitFile settings, which would be > mutually exclusive with the above, that would allow streaming of things > such as mp3s and oggs: > > SplitFile.Continuous=yes > SplitFile.Prefix=<URI fragment> > SplitFile.StartTime=<hex. insertion time of first block in seconds since > epoch> > SplitFile.BlockTime=<hex. milli-seconds between blocks> > [SplitFile.StreamInfo.<n>=<string>] > Honestly, I think this idea should go under a different name than splitfile, since it's not quite a proper extension, and will require completely different client support than normal splitfiles.
> Explanation: > > Continuous=yes indicates that this is a continuous stream, rather than a > finite splitfile. > This would be taken care of by just using a different name, and would be dropped. > Prefix is a KSK or SSK URI fragment such as > "freenet:SSK@<pubkey>/stream1/" to which hex numbers will be appended > for retrieval of each block. > > StartTime is the time in seconds since the epoch after the first block > was added. > > BlockTime is the time interval between insertion of successive blocks. > > StreamInfo are arbitrary strings which can contain additional data about > the stream (such as format etc). > Is there any reason normal info metadata shouldn't be used for this? > --- > > This may not be perfect, but it is a starting point. Someone who > understands FEC can figure out how to add FEC functionality. > > Ian. > Since I'd like to count myself as someone who understands FEC, I'll try to respond to this. For this to be useful, clients won't be able to just request one chunk every x milliseconds. Clients will have to either request more blocks every x milliseconds (expecting some of them not to come in, but still enough to FEC their way to the stream), or they'll have to buffer far enough ahead that they'll be able to have requests for additional chunks be answered before they're needed. Understanding these limitations, one can either 1) FEC sections of the stream at a time, splitting one period of time into a bunch of smaller chunks which are FEC encoded and inserted, with the understanding that getting enough of those chunks will recover the entire section of time. 2) FEC using some sort of rolling encoding where check blocks are generated to be able to recover various sections of the input stream. as an example, imagine a 6 minute stream broken into 10 second chunks: Pre FEC: 000000111111222222333333444444555555 Post FEC: 00a0a00a01b1b11a1b2bc222bc2cc23... where the a's check only for 0 blocks, b's check for 0's and 1's, c's check for 1's and 2's, ... It's possible to do this, but the pattern of check blocks, and which data blocks they check for would have to be pre-arranged. Thelema -- E-mail: thelema314 at swbell.net Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
