gavin at stephens.net.nz
Wed Dec 22 02:55:49 UTC 2021
I have the queue size customised.
I run 320Kbps bitrates by default (we're mostly all fibre over here)
along side the odd 64Kbps for monitoring, and while using burst, and a
customised queue I know roughly that a client sits at the estimated 8
seconds ahead of the queue (bitrate / 8 x 8). With the default queue,
if there are any issues with burst the clients get dropped to much where
latency is increased (ie: international).
The second reason is when I play with low bitrate streams, customising
the queue means I can have the delay to the client at roughly the same
point in time regardless of bitrate being used. But for 320Kbps, I found
the default queue not good enough. There's the opposite problem with
this though, if you don't set a queue for low bitrates for each mount
point, those low bitrate queues become reallllllllyyyyy delayed.
On 22/12/2021 11:33 am, Milton Huang wrote:
> Thank you for your detailed and enlightening answers. Just to make
> sure I understand how 'bitrate' works here. Assuming we are just
> working with audio to keep it simple. Let's also ignore metadata, as
> my use case is that I am generating an electronic music stream from
> ffmpeg and broadcasting that using Icecast, so I can control/calculate
> that. I presume that if we specify `audio_bitrate` for a particular
> mount, that is a 'target' rate that Icecast will attempt to transmit
> audio data at. You mentioned that the actual rate can vary. Am I right
> to assume this is because it is dependent on the source (ffmpeg) rate
> for filling the 'queue', which in turn is used to fill each buffer of
> each connected client?
> If so, wouldn't it generally be best for the mount `audio_bitrate` to
> be set to the same bitrate that the source is generating/sending at?
> I have the option of generating and compressing my mp3 stream at
> either a fixed bitrate or to use a LAME VBR setting, and from what I
> am now understanding it seems that using a fixed bitrate could be
> better to avoid leading or lagging the queue buffer.
> Thanks for educating all of us!
> On Thu, Dec 16, 2021 at 9:28 AM Philipp Schafft
> <phschafft at de.loewenfelsen.net <mailto:phschafft at de.loewenfelsen.net>>
> Good afternoon,
> On Wed, 2021-12-15 at 13:40 -0800, Milton Huang wrote:
> > Hi all,
> > I just want to make sure I understand what the `queue-size` setting
> > does in icecast.xml. My understanding is that for each mountpoint, a
> > buffer of that size (default 0.5 MB) is maintained for serving
> to all
> > connected clients. Each client is fed from that buffer, and if their
> > connection lags so they can't keep up with the queue contents, they
> > get kicked with a 'client has fallen too far behind' message in the
> > log.
> That is basically right. However I would like to add that the default
> queue size is fine for audio streaming and may need to be adjusted for
> video streaming. If you see a lot of said messages in logs and you are
> using the default the problem is likely not the value but something
> else (e.g. the network being saturated). Or: If you think changing
> value will help you, rethink as it likely is not.
> > I assume if we divide the queue-size by the mount's bitrate we would
> > get the duration of how slow a connection can be which is a limit on
> > possible latency of clients.
> This is wrong. Sadly a common myth.
> The 'bitrate' of a stream is generally 0) not constant, 1) only
> to the audio data, not the stream.
> as for 0) it can easily jump between 0.1% and 200% of the nominal
> for many codecs.
> as for 1) the stream consists of more than just the audio data.
> E.g. it
> contains of framing, setup headers, and metadata. Metadata can easily
> account for the same amount of data than several seconds, sometimes
> minutes of audio data.
> Keeping this in mind a useful value of a bitrate for a stream needs to
> be calculated over at least an entire segment (track/song/title)
> including all of it's metadata and format overhead. Also as metadata
> may be very different for different tracks the value may still be
> 'jumping around' a lot.
> All of that said it is surely possible to create a stream with a more
> constant or foreseeable bitrate. But this is NOT the general case.
> So you calculation above may at best give a very rough estimation.
> > On the client side, there is an input buffer to help with poor
> > connections.
> The input buffer needs to be there independent on the connection
> quality, but what a good size for it is, depends mostly on the quality
> of the connection.
> > This will be filled at the initial connection with a
> > if enabled in the icecast settings. There will be an initial
> delay in
> > play while the buffer is filled, which the burst should help
> This is perfectly correct.
> > Obviously, the burst-size has to be smaller than the queue size, or
> > you will defeat the purpose of the burst.
> This is not really true. The burst-size is a request to Icecast.
> However Icecast will not send exactly this amount of bytes as it needs
> to adhere external constrains. One of them is how much data it has. So
> setting this to an overly large value will just let Icecast send as
> much as possible.
> Other such constrains are format specific aspects such as setup
> and metadata, but also framing/syncing.
> As a small addition:
> Similar holds true for the queue-size. E.g. if Icecast has not yet got
> a full queue-size of data from a source the buffer is smaller.
> Depending on how the data is chunked (this depends on the version of
> Icecast, the format, the operating systems, the sources, the network,
> ...) the size might be slightly smaller or larger.
> Generally those values should be considered as requests and Icecast
> tries to work with them as good as possible.
> > Do I have this all right? Any comments or clarifications?
> Please see my comments inline. :)
> With best regards,
> Philipp Schafft (CEO/Geschäftsführer)
> Telephon: +49.3535 490 17 92
> Löwenfelsen UG (haftungsbeschränkt) Registration number:
> Bickinger Straße 21 HRB 12308 CB
> 04916 Herzberg (Elster) VATIN/USt-ID:
> Germany DE305133015
> Icecast mailing list
> Icecast at xiph.org <mailto:Icecast at xiph.org>
> Icecast mailing list
> Icecast at xiph.org
This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Icecast