<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I have the queue size customised.</p>
<p> 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).</p>
<p>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.</p>
<div class="moz-cite-prefix">On 22/12/2021 11:33 am, Milton Huang
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Philipp,<br>
<div><br>
</div>
<div>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?<br>
<br>
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.</div>
<div><br>
</div>
<div>Thanks for educating all of us!</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Dec 16, 2021 at 9:28
AM Philipp Schafft <<a
href="mailto:phschafft@de.loewenfelsen.net" target="_blank"
moz-do-not-send="true">phschafft@de.loewenfelsen.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good
afternoon,<br>
<br>
On Wed, 2021-12-15 at 13:40 -0800, Milton Huang wrote:<br>
> Hi all,<br>
> I just want to make sure I understand what the
`queue-size` setting<br>
> does in icecast.xml. My understanding is that for each
mountpoint, a<br>
> buffer of that size (default 0.5 MB) is maintained for
serving to all<br>
> connected clients. Each client is fed from that buffer,
and if their<br>
> connection lags so they can't keep up with the queue
contents, they<br>
> get kicked with a 'client has fallen too far behind'
message in the<br>
> log.<br>
<br>
That is basically right. However I would like to add that the
default<br>
queue size is fine for audio streaming and may need to be
adjusted for<br>
video streaming. If you see a lot of said messages in logs and
you are<br>
using the default the problem is likely not the value but
something<br>
else (e.g. the network being saturated). Or: If you think
changing this<br>
value will help you, rethink as it likely is not.<br>
<br>
<br>
> I assume if we divide the queue-size by the mount's
bitrate we would<br>
> get the duration of how slow a connection can be which is
a limit on<br>
> possible latency of clients.<br>
<br>
This is wrong. Sadly a common myth.<br>
<br>
The 'bitrate' of a stream is generally 0) not constant, 1)
only applies<br>
to the audio data, not the stream.<br>
<br>
as for 0) it can easily jump between 0.1% and 200% of the
nominal value<br>
for many codecs.<br>
<br>
as for 1) the stream consists of more than just the audio
data. E.g. it<br>
contains of framing, setup headers, and metadata. Metadata can
easily<br>
account for the same amount of data than several seconds,
sometimes<br>
minutes of audio data.<br>
<br>
Keeping this in mind a useful value of a bitrate for a stream
needs to<br>
be calculated over at least an entire segment
(track/song/title)<br>
including all of it's metadata and format overhead. Also as
metadata<br>
may be very different for different tracks the value may still
be<br>
'jumping around' a lot.<br>
<br>
<br>
All of that said it is surely possible to create a stream with
a more<br>
constant or foreseeable bitrate. But this is NOT the general
case.<br>
<br>
<br>
So you calculation above may at best give a very rough
estimation.<br>
<br>
<br>
> On the client side, there is an input buffer to help with
poor<br>
> connections.<br>
<br>
The input buffer needs to be there independent on the
connection<br>
quality, but what a good size for it is, depends mostly on the
quality<br>
of the connection.<br>
<br>
<br>
> This will be filled at the initial connection with a
burst-on-connect <br>
> if enabled in the icecast settings. There will be an
initial delay in<br>
> play while the buffer is filled, which the burst should
help reduce. <br>
<br>
This is perfectly correct.<br>
<br>
<br>
> Obviously, the burst-size has to be smaller than the
queue size, or<br>
> you will defeat the purpose of the burst.<br>
<br>
This is not really true. The burst-size is a request to
Icecast.<br>
However Icecast will not send exactly this amount of bytes as
it needs<br>
to adhere external constrains. One of them is how much data it
has. So<br>
setting this to an overly large value will just let Icecast
send as<br>
much as possible.<br>
<br>
Other such constrains are format specific aspects such as
setup headers<br>
and metadata, but also framing/syncing.<br>
<br>
<br>
As a small addition:<br>
Similar holds true for the queue-size. E.g. if Icecast has not
yet got<br>
a full queue-size of data from a source the buffer is smaller.<br>
Depending on how the data is chunked (this depends on the
version of<br>
Icecast, the format, the operating systems, the sources, the
network,<br>
...) the size might be slightly smaller or larger.<br>
<br>
Generally those values should be considered as requests and
Icecast<br>
tries to work with them as good as possible.<br>
<br>
<br>
> Do I have this all right? Any comments or clarifications?<br>
<br>
Please see my comments inline. :)<br>
<br>
<br>
With best regards,<br>
<br>
-- <br>
Philipp Schafft (CEO/Geschäftsführer) <br>
Telephon: +49.3535 490 17 92<br>
<br>
Löwenfelsen UG (haftungsbeschränkt) Registration number:<br>
Bickinger Straße 21 HRB 12308 CB<br>
04916 Herzberg (Elster) VATIN/USt-ID:<br>
Germany DE305133015<br>
_______________________________________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org" target="_blank"
moz-do-not-send="true">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/icecast"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.xiph.org/mailman/listinfo/icecast</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Icecast mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a>
</pre>
</blockquote>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>