Hello, I have a request for an additional header. This header is needed to inform the client of the burst it is going to receive. Why ? This header could be very usefull for the streaming-client to have an idea of it's delay, and (much more important) to be able to do early-on streaming. The question is not on how to implement this in code (probably send the header in the "format_prepare_headers" routine). The question is how this header should be formatted ? Should it be (most likely) something like: "icy-burst-size:262144" (for a burst buffer of 256kB) or something like: "icy-burst:20000" (for a burst of 20 seconds) - This looks somewhat like Microsoft-WMA servers notifies it's clients for bursts. If you do not wish to implement this feature, could you be so kind to define the semantics for this header (to prevent any problems in the future) ? Jelle Martijn Kok -- ------------------------------------------------------------------------ You/Com Audiocommunicatie b.v. Motorenweg 5k 2623CR Delft The Netherlands tel. : (+31)15 262 59 55 fax. : (+31)15 257 15 95 mail : jmkok@youcom.nl http : http://www.youcom.nl ------------------------------------------------------------------------
On Mon, 9 Oct 2006, Jelle Kok wrote:> The question is how this header should be formatted ? > Should it be (most likely) something like: > "icy-burst-size:262144" (for a burst buffer of 256kB) > or something like: > "icy-burst:20000" (for a burst of 20 seconds) - This looks somewhat like > Microsoft-WMA servers notifies it's clients for bursts.Since things like metadata-interval are also specified in bytes, and the burst-on-connect size is configured as bytes in the server config, it would make sense to use bytes here as well. If specified in seconds, then the header should be something like icy-burst-size-seconds. But that can never be as accurate as bytes, especially for VBR streams.> If you do not wish to implement this feature, could you be so kind to > define the semantics for this header (to prevent any problems in the > future) ?My guess would be that patches are always welcome :-) Given the application you probably have in mind (KWR) an easy workaround could be to add this information to the .PLS sent to the client. Regards, Maarten Bezemer