> Firstly, I'm one of those people who thoroughly reads through a config file > before firing up the server, so the final decision won't affect me much > from a server admin point of view. From the point of view of a listener, > I'd be happy enough for burst on connect to be the default, providing the > buffer isn't too big. I'd also like to see it be configurable, as if it's > measured in bytes, the amount of latency will depend on the bit rate. I am > constantly frustrated at shoutcast's 1 meg buffer, which runs to several > minutes at 16kbps for example.Since we know the bitrate of the stream, is there a reason to have the buffer size config parameter be in bytes? I should probably be in tenths of a second or some such more appropriate unit. Let the code do the math, instead of the humans. jack. --- >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.
> well, we know the *reported* bitrate of the stream...although, we don't do > any decoding of the stream to determine the bitrate...How do you think we read the comments? If it's not grabbing the bitrate now out of the vorbis header, it could be trivially modified to do so, since we already parse the Ogg structure. For MP3, this is even easier. So probably just extend the filetype API to add this query (get_bitrate_of_stream() or something), then use that if it's nonzero, and use the reported bitrate if it is zero (maybe there is a type which we can't tell, or for which it is too expensive to tell, or for which the bitrate varies more than is reasonable). This at least would work almost all the time. Or perhaps allow the option to be used either way: <burst-buffer>2000ms</burst-buffer> or <burst-buffer>1MB</burst-buffer>> FWIW, the default size currently set in the config was calculated assuming > a 128kbps or less stream and assuming the client buffer size to be that of > a default winamp and foobar2000 install. I haven't looked at XMMS, but I > would assume that it would coincide to the Winamp/Foobar setting..We should create a page in the wiki documenting such settings instead of poking around to look for them every time we need them. Then we can recruit others to find out information for Quicktime, iTunes, etc. jack. --- >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.
At 10:02 AM 5/17/2004, you wrote:> > Firstly, I'm one of those people who thoroughly reads through a config file > > before firing up the server, so the final decision won't affect me much > > from a server admin point of view. From the point of view of a listener, > > I'd be happy enough for burst on connect to be the default, providing the > > buffer isn't too big. I'd also like to see it be configurable, as if it's > > measured in bytes, the amount of latency will depend on the bit rate. I am > > constantly frustrated at shoutcast's 1 meg buffer, which runs to several > > minutes at 16kbps for example. > >Since we know the bitrate of the stream, is there a reason to have the >buffer size config parameter be in bytes? I should probably be in >tenths of a second or some such more appropriate unit. Let the code do >the math, instead of the humans.well, we know the *reported* bitrate of the stream...although, we don't do any decoding of the stream to determine the bitrate...so it would seem iffy at best to reliably get the "bitrate" of the stream to perform this calculation...unless I am missing something...And that calculation also might get even more complicated when we are talking about mutliple codec streams (OggTheora+Vorbis)... FWIW, the default size currently set in the config was calculated assuming a 128kbps or less stream and assuming the client buffer size to be that of a default winamp and foobar2000 install. I haven't looked at XMMS, but I would assume that it would coincide to the Winamp/Foobar setting.. oddsock>jack. >--- >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.<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.
On Mon, 2004-05-17 at 16:14, oddsock wrote:> >Since we know the bitrate of the stream, is there a reason to have the > >buffer size config parameter be in bytes? I should probably be in > >tenths of a second or some such more appropriate unit. Let the code do > >the math, instead of the humans. > > well, we know the *reported* bitrate of the stream...although, we don't do > any decoding of the stream to determine the bitrate...so it would seem iffy > at best to reliably get the "bitrate" of the stream to perform this > calculation...unless I am missing something...And that calculation also > might get even more complicated when we are talking about mutliple codec > streams (OggTheora+Vorbis)...VBR mp3 as well, 1 Meg is far too much for current audio players, most default to 128k buffer with a prebuffer of 50%. That's why I made the default burst in the kh tree 64k. No doubt video+audio streams should have more, but you have the added issue of key frame handling. As long as a reasonable threshold is set, as you still have network lag considerations for some listeners. karl. <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.