Hi Mike, find the patch for faststart that takes in account different logical streams. I tried with ices' playlist, it works just fine [*]. I could be still further optimised, but it will make the code less clear (for example, I could check for has_paredata before checking for serailno, which saves a couple of calls and also will avoid any change in format_mp3.[ch]). <p>[*] We must rethink the hard limit, 25, in the queue size, the queue can become larger just with the faststart buffer. A limit in _seconds_ could work better. <p> -- ricardo galli GPG id C8114D34 -------------- next part -------------- A non-text attachment was scrubbed... Name: update3b.diff Type: text/x-diff Size: 10015 bytes Desc: update3b.diff Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20030119/b6b0bdfd/update3b.bin
On Monday 20 January 2003 15:13, Michael Smith shaped the electrons to shout:> There's already too much format-specific knowledge in the core, this > get_serialno() thing has no chance of going in.Only a stream id, which also could be called "stream_id", I don't think is "too much knowledge". Nevertheless, I will change it if you are still interested, but please, give some clues of _your_ thoughts before I send the patch (I asked about this issue several times in the last days).> The right way to do this is to move it all entirely into get_predata(),This a good clue.> and have a default implementation of that (for mp3 to use, for example, > as well as any other formats that get added in the future) that only > does the 'faststart' stuff. The vorbis implementation will obviously > need to do more than just this one thing. > > It also needs to be defaulted to off, this isn't a feature everyone > should get without thinking about whether they want to use it.OK. For doing all of these, and perhaps to implement more complex flow control policies in the future (as you suggest), I would like to clean up source_main by moving the logic of sending the client queue to another function. I've already got the patch, I'll sent it in few minutes, after I finish the tests. <p> -- ricardo galli GPG id C8114D34 --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Monday 20 January 2003 06:16, Ricardo Galli wrote:> Hi Mike, > find the patch for faststart that takes in account different logical > streams. I tried with ices' playlist, it works just fine [*]. > > I could be still further optimised, but it will make the code less clear > (for example, I could check for has_paredata before checking for > serailno, which saves a couple of calls and also will avoid any change in > format_mp3.[ch]). ><p>There's already too much format-specific knowledge in the core, this get_serialno() thing has no chance of going in. The right way to do this is to move it all entirely into get_predata(), and have a default implementation of that (for mp3 to use, for example, as well as any other formats that get added in the future) that only does the 'faststart' stuff. The vorbis implementation will obviously need to do more than just this one thing. It also needs to be defaulted to off, this isn't a feature everyone should get without thinking about whether they want to use it.> > [*] We must rethink the hard limit, 25, in the queue size, the queue can > become larger just with the faststart buffer. A limit in _seconds_ could > work better.Right, I know that limit is a problem. Time-based limits are much harder, as they require deeper format knowledge than is currently done (unless you use a hack like in your faststart stuff - but I don't really like that, either. A byte-length buffer rather than time-based makes more sense anyway, since most (all?) clients do buffering based on a fixed buffer size, not a length of time. Mike <p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.