<div dir="ltr">hey, <div><br></div><div> I cast itself can not re encode a stream, you would have to use something like dark ice or vlc to set up as a listener and then source the new encoded stream on another mount point. The external program will encode the stream in what ever format is needed. Mp3 are private and can run into use laws and Ogg is ope n to use. I not seen any body taken town because of it yet.</div><div><br></div><div>I would worry more about the internet <span style="font-size:12.8px">latency </span>then worry about much <span style="font-size:12.8px">latency is added with re encoding. Offering slower encoding should help out those who don't have faster internet. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">DAvid. </span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 28, 2017 at 11:11 AM, Jack Elliott <span dir="ltr"><<a href="mailto:thatjackelliott@kpov.org" target="_blank">thatjackelliott@kpov.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<p>"Live streams are not live, they can be up to 15 to 20 sec off
original encoding." <br>
</p>
</span><p>Something you become aware of very quickly when you're announcing
into a mic and have to wait to hear your words! <br>
</p>
<p>We do a bit of pre-show calibration with folks at the station to
determine how long the delay ("latency" in digital-speak) is at
the start of the remote broadcast, and start our remote announcing
that number of seconds before the start of the show so they come
out of the buffers at the right time. And at the end of the
remote's broadcast day, we do the same as latency tends to build
up over the period of the show. We often say, "and thank you for
listening," a full 30 seconds before the scheduled end of the
remote so that the studio programming can take over at the
scheduled time. <br>
</p>
<p>For our setup there are two listen-clients: we knuckleheads
monitoring at the remote event, and a listen-client at the studio,
which feeds the broadcast console and thence to our radio
listeners. The listen client at the station won't fall too far
behind because it's on the same LAN as the Icecast server. It's us
knuckleheads out at the remote, checking in with the stream to
assure that our stream is getting to the server, who can get
kicked off due to falling too far behind. <br>
</p>
<p>For music-grade stereo sound we encode to 192kbps mp3. Ogg might
be better-sounding, but they use iTunes and/or Windows Media
Player at the station to play the stream and mp3 is your lowest
common denominator. They fear change at the studio.<br>
</p>
<p><u>Question</u>: can the icecast server be set up with two
listen-client mountpoints? Both using the same source-client
mountpoint, with one listen-client mountpoint for studio playback
at the encoded bitrate, and a second listen-client mountpoint
re-encoded to a lower bitrate for us knuckleheads to use at the
remote end to monitor? That may add additional latency for the
re-encoding but it might be more reliable.<br>
</p><span class="">
<pre class="m_3382101291110434137moz-signature" cols="72">--
That Jack Elliott
<a href="tel:(541)%20848-7021" value="+15418487021" target="_blank">(541) 848 7021</a>
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics
</pre>
</span><div><div class="h5"><div class="m_3382101291110434137moz-cite-prefix">On 04/27/2017 08:36 AM, David Saunders
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hey,
<div><br>
</div>
<div> Something about streaming. </div>
<div> </div>
<div> Live streams are not live, they can be up to 15 to
20 sec off original encoding. This is to to overhead on both
the server and client for encoding/decoding the stream, Any
trans coding, and and buffering that has to be done on a
"slow" connection. Unless the client decoder has some way to
sync the stream, this delay will grow tell icecast server
decides I have no more buffer t back into and drops them.
This can be really pronounced if the connection jumps through
a satellite.</div>
<div><br>
</div>
<div>You can help this by maxing out the following settings: </div>
queue-size : This is the buffer you want to allow the client
to fall behind.
<div>burst-size: This is how much data you want to fill
send to the client when they connect to fill up the client
buffers. </div>
<div><br>
</div>
<div>You can also provide a lower quality stream(lower
bandwidth) for those who have bad connections. </div>
<div><br>
</div>
<div> What I do is if we get allot of slow listeners, I go
though the log determined how many unique one are falling out
of the queue. And tweak up the queue size or offer a lower
quality connection to them when they connect again :) Since
we from time to time have issues with connection spammers.
(They connect to the server 1000/sec, and the slow listens sky
rocket) I use a php traffic controller and black list on the
icecast server to insure the best experience for our
listeners. </div>
<div><br>
</div>
<div> Just remember, setup the streams at the lowest possible
encoding as you can. There are people who still are not on
broadband connections around the world. </div>
<div><br>
</div>
<div>David.</div>
<div><br>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Apr 27, 2017 at 12:58 AM, Jack
Elliott <span dir="ltr"><<a href="mailto:thatjackelliott@kpov.org" target="_blank">thatjackelliott@kpov.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Thanks, Brad -- I first turned to VLC but my
stream-client device is a Raspberry Pi 3, and there
doesn't seem to be a build for the device. That said, I
just stumbled across mpg123, a command-line mp3/stream
player that has audio buffer and timeout setting which
so far looks quite robust.</p>
<p>For Icecast2 content, when Icecast kicks a client off
for being "too far behind" -- what is "too far"?<br>
</p>
<span>
<pre class="m_3382101291110434137m_2148754537603914082moz-signature" cols="72">--
That Jack Elliott
<a href="tel:%28541%29%20848-7021" value="+15418487021" target="_blank">(541) 848 7021</a>
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics
</pre>
</span>
<div>
<div class="m_3382101291110434137h5">
<div class="m_3382101291110434137m_2148754537603914082moz-cite-prefix">On
04/26/2017 08:10 PM, Brad Isbell wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Simply use VLC and put it on repeat.
If a connection is lost during playback, it will
reconnect and pick up in the current live
position, like you have suggested, without
stopping. If it cannot reconnect after 3 times,
it goes to the next playlist item. If the
playlist is on repeat, it runs indefinitely.<br>
<div class="gmail_extra"><br clear="all">
<div>
<div class="m_3382101291110434137m_2148754537603914082gmail_signature" data-smartmail="gmail_signature">Brad Isbell<br>
<a href="mailto:brad@musatcha.com" target="_blank">brad@musatcha.com</a><br>
<a href="http://www.musatcha.com" target="_blank">http://www.musatcha.com</a></div>
</div>
<br>
<div class="gmail_quote">On Wed, Apr 26, 2017 at
1:58 PM, Jack Elliott <span dir="ltr"><<a href="mailto:thatjackelliott@kpov.org" target="_blank">thatjackelliott@kpov.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's behaving
as it is meant to: if a listen client gets
too far behind, Icecast2 server is kicking
them off.<br>
<br>
error.log says,<br>
<br>
"INFO source/source.c Client 120
(xxx.xxx.xxx.xxx) has fallen too far behind,
removing"<br>
<br>
I don't see a setting in icecast.xml that
sets the value for "too far behind". I'm
guessing it's related to <queue-size>.<br>
<br>
I wish Icecast could dump the buffer and
bring the listen-client back up to date
instead of dumping the client. The reason
being that when network congestion causes
Icecast to kick my listen-client off, the
client application just gives up. And this
is a listen-client I'd like to have running
24/7 so I can monitor the station's backroom
server when we are doing all-day music
remotes.<br>
<br>
I haven't found a media/url player that
attempts re-connect when kicked off. At
least under Linux. On Windows a player
called AIMP3 works great: if it is
disconnected from the server, it tries to
reconnect. Over and over and over. I like
that behavior.<span class="m_3382101291110434137m_2148754537603914082HOEnZb"><font color="#888888"><br>
<br>
-- <br>
That Jack Elliott<br>
<a href="tel:%28541%29%20848%207021" value="+15418487021" target="_blank">(541)
848 7021</a><br>
KPOV 88.9 FM High Desert Community radio<br>
Producer, The Wednesday Point<br>
Host, The Sunday Classics<br>
<br>
______________________________<wbr>_________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/" target="_blank">http://lists.xiph.org/mailman/</a><wbr>listinfo/icecast<br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/icecast" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/icecast</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>