At 08:11 AM 1/19/2006, Karl Heyes wrote:>Geoff Shang wrote: >>Karl Heyes wrote: >> >>>To maintain consistency, no timing occurs on the fallback to file >>>as that requires parsing of all formats. >> >>hmmm, good point, but it obviously breaks fallback-override (as far >>as it's useful), and also could cause your outgoing bandwidth to be swamped. > >It's not that fallback override breaks, but there may be lot of >stream data sent to that listener. There is a delay each time around >the main handler to limit busy looping. > >>Suggestion: How about allowing the admin to configure a bitrate for >>the fallback file. This would make it their responsibility to get >>it right, but would solve both of the above. > >That is certainly possible, I was wondering about implementing such >a mechanism as a simple regulator but never got around to implementing it.personally I wouldn't mind seeing the fallback to file implemented as a simple source loop creation. This would create another source thread (inefficient maybe, but then it could be treated just like any other source). This would also add another dependency to icecast (it would add libshout), which might be a bit problematic, but still worth looking at...I know icecast already shares a lot of code with libshout oddsock
oddsock wrote:> At 08:11 AM 1/19/2006, Karl Heyes wrote:>> That is certainly possible, I was wondering about implementing such a >> mechanism as a simple regulator but never got around to implementing it. > > > personally I wouldn't mind seeing the fallback to file implemented as a > simple source loop creation. This would create another source thread > (inefficient maybe, but then it could be treated just like any other > source). This would also add another dependency to icecast (it would > add libshout), which might be a bit problematic, but still worth looking > at...I know icecast already shares a lot of code with libshoutlibshout could be a mechanism to use and it would regulate the rate at which ogg and mp3 streams are sent through, what it won't time is anything like aac or nsv, so it would be question of what do we aim for. Adding libshout could also be used for implementing push relays. karl.
Karl Heyes wrote:> Adding libshout could also be used for implementing push relays.That would be a nice feature to have. Geoff.
Hi All, Got a question about multiple streams that I'm a bit confused about. What I want to do is send a 128Kbps stream up to the server and then have the server split this into 128, 56 and 24 Kbps streams. My question is: What is the best tool for this and what is the process? I'm guessing that ICES is the tool that I need but thought I'd ask before I spent more time on it in case there is a better alternative. Thanks Very Much, Andy