[Icecast] queue-size

[Philipp Schafft]

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 this
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 applies
to the audio data, not the stream.

as for 0) it can easily jump between 0.1% and 200% of the nominal value
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 burst-on-connect 
> if enabled in the icecast settings. There will be an initial delay in
> play while the buffer is filled, which the burst should help reduce. 

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 headers
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211216/4887bb5a/attachment.sig>