Commit d30d192b authored by Marvin Scholz's avatar Marvin Scholz

Add mkdocs to repo and generate them with automake

parent b7087c38
......@@ -141,6 +141,21 @@ XIPH_PATH_OPENSSL([
[ AC_MSG_NOTICE([SSL disabled!])
])
dnl Documentation
AC_PATH_PROG([MKDOCS], [mkdocs], [no])
AS_IF([test "$MKDOCS" = "no"], [
AC_MSG_WARN([mkdocs not found - generating docs will be disabled])
])
AM_CONDITIONAL([HAVE_MKDOCS], [test ! "$MKDOCS" = "no"])
AM_COND_IF([HAVE_MKDOCS], [
AC_CONFIG_FILES([doc/mkdocs.yml])
])
dnl Make substitutions
AC_SUBST(XIPH_CPPFLAGS)
......@@ -161,8 +176,6 @@ AC_SUBST(KATE_LIBS)
AC_OUTPUT([Makefile conf/Makefile src/Makefile src/common/avl/Makefile
src/common/httpp/Makefile src/common/thread/Makefile src/common/log/Makefile
src/common/net/Makefile src/common/timing/Makefile doc/Makefile doc/img/Makefile
doc/assets/Makefile doc/assets/css/Makefile doc/assets/font/Makefile
doc/assets/img/Makefile web/Makefile web/assets/Makefile web/assets/css/Makefile
src/common/net/Makefile src/common/timing/Makefile doc/Makefile web/Makefile web/assets/Makefile web/assets/css/Makefile
web/assets/font/Makefile admin/Makefile admin/includes/Makefile win32/Makefile
examples/Makefile])
## Process this file with automake to produce Makefile.in
AUTOMAKE_OPTIONS = foreign
SUBDIRS = assets img
EXTRA_DIST = \
mkdocs.yml \
docs/img/icecast_shema.svg \
docs/admin_interface.md \
docs/auth.md \
docs/basic_setup.md \
docs/config_file.md \
docs/index.md \
docs/introduction.md \
docs/relaying.md \
docs/server_stats.md \
docs/win32.md \
docs/yp.md
docdir = $(datadir)/doc/icecast
doc_DATA = admin-interface.html auth.html changes.html faq.html \
introduction.html relaying.html win32.html basic-setup.html \
config-file.html glossary.html index.html server-stats.html yp.html
EXTRA_DIST = $(doc_DATA)
# Documentation generation
if HAVE_MKDOCS
# Directory where the docs will end up
directory = $(top_srcdir)/doc/icecast/
EXTRA_DIST += $(directory)
mkdocs.stamp:
cd "$(top_srcdir)/doc" && $(MKDOCS) build -d "$(directory)"
echo STAMP > mkdocs.stamp
CLEANFILES = mkdocs.stamp
install-data-local:
echo FIXMEFIXMEFIXME
exit
$(INSTALL) -d "$(directory)" "$(docdir)"
uninstall-local:
( cd "$(directory)"; find . -type f -print0) | (cd "$(docdir)"; xargs -0 rm )
all-local: mkdocs.stamp
clean-local:
rm -rf "$(directory)"
endif
<!DOCTYPE html>
<html lang="en">
<head>
<title>Icecast Docs Docs &mdash; Admin Interface</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="assets/css/style.css" media="screen, print" />
</head>
<body>
<div class="header">
<h1><a href="#" title="Home page">Icecast</a> <span>documentation</span></h1>
</div>
<div class="section">
<h2>Icecast 2.4.99.1 Docs &mdash; Admin Interface</h2>
<div class="article">
<h3 id="overview">Overview</h3>
<p>This section contains information about the admin interface of icecast. Through this interface the user can manipulate many server features. From it you can gather statistics, move listeners from mountpoint to mountpoint, disconnect connected sources, disconnect connected listeners, and many other activities. Each function is enumerated here as well as an example usage of the function.</p>
<p>Each of these functions requires HTTP authentication via the appropriate username and password. For mount-specific functions, you may use either the <code>&lt;admin-username&gt;</code> and <code>&lt;admin-password&gt;</code> specified in the icecast config file, or the username and password specified for that mountpoint (if any). For general functions (not specific to a single mountpoint), you must use the admin username and password. It is also important to note that in all the examples 192.168.1.10 is used as the example host and 8000 is used as the example port for the icecast server.</p>
</div>
<div class="article">
<h3 id="admin-functions-mount-specific">Admin Functions (mount specific)</h3>
<p>All these admin functions are mount specific in that they only apply to a particular mountpoint
(as opposed to applying to the entire server). Each of these functions requires a mountpoint to
be specified as input.</p>
<h4 id="metadata-update">Metadata Update</h4>
<p>This function provides the ability for either a source client or any external program to update
the metadata information for a particular mountpoint.</p>
<p>Example:<br />
<code>http://192.168.1.10:8000/admin/metadata?mount=/mystream&amp;mode=updinfo&amp;song=ACDC+Back+In+Black</code></p>
<h4 id="fallback-update">Fallback Update</h4>
<p>This function provides the ability for either a source client or any external program to update the
“fallback mountpoint” for a particular mountpoint. Fallback mounts are those that are used in the even
of a source client disconnection. If a source client disconnects for some reason that all currently
connected clients are sent immediately to the fallback mountpoint.</p>
<p>Example:<br />
<code>http://192.168.1.10:8000/admin/fallbacks?mount=/mystream.ogg&amp;fallback=/myfallback.ogg</code></p>
<h4 id="list-clients">List Clients</h4>
<p>This function lists all the clients currently connected to a specific mountpoint. The results are sent
back in XML form.</p>
<p>Example:<br />
<code>http://192.168.1.10:8000/admin/listclients?mount=/mystream.ogg</code></p>
<h4 id="move-clients-listeners">Move Clients (Listeners)</h4>
<p>This function provides the ability to migrate currently connected listeners from one mountpoint to another.
This function requires 2 mountpoints to be passed in: mount (the <em>from</em> mountpoint) and destination
(the <em>to</em> mountpoint). After processing this function all currently connected listeners on mount will
be connected to destination. Note that the destination mountpoint must exist and have a sounce client
already feeding it a stream.</p>
<p>Example:
<code>http://192.168.1.10:8000/admin/moveclients?mount=/mystream.ogg&amp;destination=/mynewstream.ogg</code></p>
<h4 id="kill-client-listener">Kill Client (Listener)</h4>
<p>This function provides the ability to disconnect a specific listener of a currently connected mountpoint.
Listeners are identified by a unique id that can be retrieved by via the “List Clients” admin function.
This id must be passed in to the request via the variable <code>id</code>. After processing this request, the listener will no longer be
connected to the mountpoint.</p>
<p>Example:
<code>http://192.168.1.10:8000/admin/killclient?mount=/mystream.ogg&amp;id=21</code></p>
<h4 id="kill-source">Kill Source</h4>
<p>This function will provide the ability to disconnect a specific mountpoint from the server. The mountpoint
to be disconnected is specified via the variable <code>mount</code>.</p>
<p>Example:
<code>http://192.168.1.10:8000/admin/killsource?mount=/mystream.ogg</code></p>
</div>
<div class="article">
<h3 id="admin-functions-general">Admin Functions (general)</h3>
<h4 id="stats">Stats</h4>
<p>The stats function provides the ability to query the internal statistics kept by the Icecast server.
Almost all information about the internal workings of the server such as the mountpoints connected,
how many client requests have been served, how many listeners for each mountpoint, etc, are available
via this admin function.<br />
Note that this admin function can also be invoked via the http://server:port/admin/stats.xml syntax,
however this syntax should not be used and will eventually become deprecated!</p>
<p>Example:<br />
<code>http://192.168.1.10:8000/admin/stats</code></p>
<h4 id="list-mounts">List Mounts</h4>
<p>The list mounts function provides the ability to view all the currently connected mountpoints.</p>
<p>Example:
<code>http://192.168.1.10:8000/admin/listmounts</code></p>
</div>
<div class="article">
<h3 id="web-based-admin-interface">Web-Based Admin Interface</h3>
<p>As an alternative to manually invoking these URLs, a web-based admin interface was developed. This
interface provides the same functions that were identified and described above but presents them in
a little nicer way. The web-based admin Interface to Icecast is shipped with Icecast provided in the
<code>admin</code> directory and comes ready to use. All the user needs to do is set the path to this directory
in the config file via the <code>&lt;adminroot&gt;</code> config variable.<br />
The web-based admin interface is a series of XSLT files which are used to display all the XML obtained
via the URL admin interface. This can be changed and modified to suit the user’s need. Knowledge of
XSLT and transformations from XML to HTML are required in order to make changes to these scripts. </p>
<p>The main URL for the Web-Based Admin Interface is:<br />
<code>http://192.168.1.10:8000/admin/stats.xsl</code> </p>
<p>From this URL all of the other admin functions can be exercised.
<strong>Modification of existing XSLT transforms in <code>/admin</code> is allowed, but new files cannot be created here</strong>.
Creation of new XSLT transforms as well as modification of existing transforms is allowed in <code>/web</code>.
These work using the document returned by <code>/admin/stats.xml</code>.<br />
To see the XML document that is applied to each admin XSLT, just remove the <code>.xsl</code> in your request
(i.e. <code>/admin/listclients</code>). You can then code your XSLT transform accordingly.</p>
</div>
</div>
<div class="footer">
<p>Support icecast development at <a href="http://icecast.org">icecast.org</a></p>
</div>
</body>
</html>
## Process this file with automake to produce Makefile.in
AUTOMAKE_OPTIONS = foreign
SUBDIRS = css font img
## Process this file with automake to produce Makefile.in
AUTOMAKE_OPTIONS = foreign
otherdocdir = $(docdir)/assets/css
otherdoc_DATA = style.css
EXTRA_DIST = $(otherdoc_DATA)
This diff is collapsed.
## Process this file with automake to produce Makefile.in
AUTOMAKE_OPTIONS = foreign
otherdocdir = $(docdir)/assets/font
otherdoc_DATA = FiraMono-Bold.eot FiraMono-Regular.eot \
FiraSans-Bold.eot FiraSans-BoldItalic.woff \
FiraSans-Italic.eot FiraSans-Regular.eot \
FiraMono-Bold.woff FiraMono-Regular.woff \
FiraSans-BoldItalic.eot FiraSans-Bold.woff \
FiraSans-Italic.woff FiraSans-Regular.woff
EXTRA_DIST = $(otherdoc_DATA)
## Process this file with automake to produce Makefile.in
AUTOMAKE_OPTIONS = foreign
otherdocdir = $(docdir)/assets/img
otherdoc_DATA = xiph-community.svg
EXTRA_DIST = $(otherdoc_DATA)
This diff is collapsed.
This diff is collapsed.
<!DOCTYPE html>
<html lang="en">
<head>
<title>Icecast Docs Docs &mdash; Basic Setup</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="assets/css/style.css" media="screen, print" />
</head>
<body>
<div class="header">
<h1><a href="#" title="Home page">Icecast</a> <span>documentation</span></h1>
</div>
<div class="section">
<h2>Icecast 2.4.99.1 Docs &mdash; Basic Setup</h2>
<div class="article">
<h3 id="basic-requirements">Basic Requirements</h3>
<p>This section will describe the essential requirements in setting up a simple Internet radio station. It is by no means a complete list but should give you enough to get started. Please also note that those are generic instructions. If you installed a Linux/Unix distribution package, then it will likely come with different paths, different means of starting it, etc. In that case please also refer to the documentation of that distribution and or a distribution specific How-To.</p>
<p>There are two major components involved: the streaming server (Icecast in this case) and the source client.<br />
The Icecast server will be the place where all listeners of your station will connect. The source client (in general) runs on a separate machine than Icecast, but does not necessarily need to. Source clients send the content to Icecast and provide the stream data (encoded audio) that is then relayed out to listeners by Icecast.</p>
<p>It is important to note that not all source clients work with Icecast 2. You will need to check to make sure that Icecast 2 is supported by your chosen source client.</p>
</div>
<div class="article">
<h3 id="the-basics">The Basics</h3>
<p>Each Icecast server can house multiple broadcasts (or mountpoints) each containing a separate stream of content. A ‘mountpoint’ is a unique name on your server identifying a particular stream - it looks like a filename, such as ‘/stream.ogg’. A listener can only listen to a single mountpoint at a time. This means you can have a single Icecast server contain either multiple broadcasts with different content, or possibly the same broadcast but with streams of different bitrates or qualities. In this case each broadcast or stream is a separate mountpoint.</p>
<p>At this point, the steps outlined here related to the Unix version or Win32 console version of Icecast. Icecast is also available in a Win32 GUI version, and the steps are similar in setup, but not quite the same.</p>
<p>The first step in the process is to find and install the Icecast2 server itself. How to do this is not contained within this documentation. After installation you should have and Icecast binary and 3 directories</p>
<ul>
<li><code>conf</code><br />
Contains the Icecast configuration file (<code>icecast.xml</code>) which defines all the configuration parameters for the server. </li>
<li><code>admin</code><br />
Contains xslt files which are used by the Icecast server to provide a web-based front end to the administration capabilities of the server. </li>
<li><code>logs</code><br />
This is a blank directory which (if specified in the config file) will contain all the logs (there are 2) for Icecast. </li>
</ul>
<p>The next step is to edit the <code>icecast.xml</code> file and set the appropriate values. Most of the specified values in the samples are fine, for a basic setup the following entries should be specified, and if neccessary, changed to suite your situation:</p>
<p><code>&lt;hostname&gt;</code> - DNS name or IP address used for stream directory listings.<br />
<code>&lt;source-password&gt;</code> - Will be used for the source client authentication.<br />
<code>&lt;admin-password&gt;</code> - Will be used for authenticating admin features of Icecast.<br />
<code>&lt;listen-socket&gt;</code> (both port and bind-address) </p>
<p>Once the configuration file is modified, you should be able to start the server with the following command</p>
<pre><code>icecast -c /path/to/icecast.xml
</code></pre>
<p>If no error messages are generated, then check the <code>error.log</code> file for the ‘server started’ message, it will look something like :</p>
<pre><code>[2003-10-31 13:04:49] INFO main/main.c Icecast 2.3.0 server started
</code></pre>
<p>You may notice slight variations to the line above, the time will no doubt be different, and on some platforms the <code>main.c</code> is just main, but the key thing here is that the server is started, logging is working and the version is shown. </p>
<p>You can also verify that it started by visiting the following URL: <code>http://yourip:port/admin/stats.xml</code>. You should be prompted for a username and password. Enter the username <code>admin</code> and the password you entered for <code>&lt;admin-password&gt;</code>. If all is well, you should see an small XML tree which represents Icecast statistics (more about that later). </p>
<p>Now that the Icecast server is started you must now configure your source client. The information you will need for the source client is the following: </p>
<p>IP address and Port of the icecast server - both of these come from <code>&lt;listen-socket&gt;</code><br />
source password - from <code>&lt;source-password&gt;</code> </p>
<p>Additionally, you will need to choose a mountpoint and specify this in the source client. Icecast does not need to know about each mount point (although you can configure settings for specific mountpoint - this is covered under Advanced configuration) there are, however, some points to mention regarding mountpoints. All Ogg Vorbis streams should have mountpoints that end in <code>.ogg</code> (i,e. <code>/mystream.ogg</code>). This is due to the lazy way most media players infer the type of stream. MP3 streams usually do not contain an extension (/mystream). Mount points also should not contain any spaces or odd characters (again due to the lazy way many of the media players are coded). </p>
<p>Once you have configured your source client, you should be able to connect it to the Icecast server. Verify that it is connected by hitting the stats.xml URL that was mentioned above. </p>
<p>Now that you have the source connnected, listening to the stream involves simply opening the appropriate following URL in a browser: <code>http://yourip:port/mounpoint-you-specified</code>. So, for instance, if you attached your source client to an icecast server located at <code>192.0.2.23:8000</code> with a mountpoint of <code>/mystream.ogg</code>, then you would open: <code>http://192.0.2.23:8000/mystream.ogg</code> or <code>http://192.0.2.23:8000/mystream.ogg.m3u</code>. Note that the URL with <code>.m3u</code> extention will serve up a link that opens most media players. Also it is important to note that m3u need not contain only MP3 stream, it can contain streams of arbitrary content-type and is used by Icecast to serve a playlist that represents your broadcast to listening clients. Alternatively you can open up the stream URL directly within your media player (<code>http://192.0.2.23:8000/mystream.ogg</code> in this case)</p>
</div>
</div>
<div class="footer">
<p>Support icecast development at <a href="http://icecast.org">icecast.org</a></p>
</div>
</body>
</html>
<!DOCTYPE html>
<html lang="en">
<head>
<title>Icecast Docs Docs &mdash; Changes</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="assets/css/style.css" media="screen, print" />
</head>
<body>
<div class="header">
<h1><a href="#" title="Home page">Icecast</a> <span>documentation</span></h1>
</div>
<div class="section">
<h2>Icecast 2.4.99.1 Docs &mdash; Changes</h2>
<div id="v2.4.99.1" class="article">
<h3 id="version-24991">Version 2.4.99.1</h3>
<!-- FIXME -->
<ul>
<li>Roles</li>
<li>Events</li>
<li>Stuff</li>
<li>Read ChangeLog for details</li>
</ul>
<div id="v2.4.1" class="article">
<h3 id="version-241">Version 2.4.1</h3>
<h4 id="fixes">Fixes</h4>
<ul>
<li>Fixed cross-corruption of file descriptors by on-connect/on-disconnect scripts, specifically STDIN, STDOUT and STDERRR vs TCP connections.
<ul>
<li>We actually close not just 0, 1 and 2, but the first 1024 FDs, which seems common trade-off practice, but still not ideal. A more thorough fix will need platform specific logic and significant work.</li>
<li>The STDIN/OUT/ERR problem is fixed reliably, but other problems could occur if both the script and the server use FDs &gt;1024 at the same time</li>
<li>This is now reasonably safe, but care should be exercised nevertheless. </li>
</ul>
</li>
<li>Disabled SSLv3 and SSL compression explicitly to improve security</li>
<li>Updated the default ciphers to be more secure</li>
<li>Fixed JSON status API problems
<ul>
<li>Put the XSLT last item check into every filtered tag.</li>
<li>This way we shouldn’t run into problems of this type anymore.</li>
<li>Also it should be easier to customize the XSLT this way, if someone wants to filter differently.</li>
</ul>
</li>
<li>Fixed <code>&lt;auth&gt;</code> in <code>&lt;mount type="default"&gt;</code> to work properly.</li>
<li>Fixed listener connection duration logging in access.log. Regression was introduced for only some platforms by an earlier security fix.</li>
<li>Fixed time zone reporting in _iso8601 fields on Windows.</li>
<li>added warnings on empty and default values of <code>&lt;fileserve&gt;</code>, <code>&lt;hostname&gt;</code>, <code>&lt;location&gt;</code>, <code>&lt;admin&gt;</code> and <code>&lt;server-id&gt;</code></li>
<li>send errorlog (loglevel WARN) to stderr prior to opening logfiles.</li>
<li>Fixed handling of empty strings in config file. Now empty strings are handled in: accesslog, errorlog, logdir, webroot, adminroot and hopefully all kinds of port.</li>
<li>Be more verbose in case of fileserve off. People disable fileserve and then wonder why the web interface CSS breaks.</li>
<li>More details in log messages
<ul>
<li>Add source IP adress to startup and source exit logging</li>
<li>Add mountpoint to some log lines</li>
</ul>
</li>
<li>Updated the config file to avoid common pitfalls and make some things more obvious.</li>
<li>Fixed some compiler warnings</li>
<li>Fixed autogen.sh to work properly on Mac OS</li>
<li>Fixed JSON access by adding support for global and mount specific custom HTTP headers.
<ul>
<li>The purpose is to fix JSON access from browsers, by supporting basic CORS use cases. This is both important for some HTML5 <code>&lt;audio&gt;</code> or <code>&lt;video&gt;</code> use cases and accessing the JSON status API.</li>
<li>The default icecast config contains the very permissive global header: &lt;header name="Access-Control-Allow-Origin" value="*" /&gt;</li>
</ul>
</li>
</ul>
<h4 id="known-issues">Known issues</h4>
<ul>
<li>HTTP PUT implementation currently doesn’t support chunked encoding yet.</li>
<li>HTTP PUT with “Expect: 100-Continue” receives first a “100” and soon after a “200”, instead of the “200” at the end of transmission.</li>
<li>Caution should be exercised when using <code>&lt;on-connect&gt;</code> or <code>&lt;on-disconnect&gt;</code>, as there is a small chance of stream file descriptors being mixed up with script file descriptors, if the FD numbers go above 1024. This will be further addressed in the next Icecast release.</li>
<li>Don’t use comments inside <code>&lt;http-headers&gt;</code> as it will prevent processing of further <code>&lt;header&gt;</code> tags.</li>
</ul>
</div>
<div id="v2.4.0" class="article">
<h3 id="version-240">Version 2.4.0</h3>
<h4 id="new-features">New Features</h4>
<ul>
<li>Support for Ogg Opus streams</li>
<li>Support for WebM streams</li>
<li>HTTP 1.1 PUT support for source connections. Deprecating SOURCE method</li>
<li><em>Default mount</em><br />
This allows you to define a global set of defaults for ALL mounts. This way you can use e.g. url-auth for sources and or listeners also for dynamically generated mounts.</li>
<li><em>Web interface redone</em>
<ul>
<li>Web output properly redone, credit to ePirat</li>
<li>Added <code>&lt;audio&gt;</code> element for supported audio streams</li>
<li>Now validates completely as XHTML1.0 strict</li>
<li>Also improves rendering on mobile devices</li>
</ul>
</li>
<li>Added basic JSON API (<code>/status-json.xsl</code>) based on a xml2json template by Doeke Zanstra (see <code>xml2json.xslt</code>). Output is roughly limited to data also visible through <code>status.xsl</code></li>
<li>Send charset in HTTP headers for everything, excluding file-serv and streams</li>
<li>Allow (standard strftime(3)) <code>%x</code> codes in <code>&lt;dump-file&gt;</code>. Disabled for Win32</li>
<li>Added <code>stream_start_iso8601</code>, <code>server_start_iso8601</code> to statitics. ISO8601 compliante timestamps for statistics. Should make usage in e.g. JSON much easier. Added as new variables to avoid breaking backwards compatibility</li>
<li>Now compiles for Win32 using mingw</li>
<li>Added options <code>headers</code> and <code>header_prefix</code> to URL based listener auth</li>
<li>Updated <code>listener_remove</code> handler, added <code>ip=</code> and <code>agent=</code></li>
<li>Allow full URLs to be returned by the master server</li>
</ul>
<h4 id="fixes-1">Fixes</h4>
<ul>
<li><strong>Security fix</strong>: Override supplementary groups if is used</li>
<li>Fixes for some race conditions</li>
<li>Dropped debian packaging directory as debian use their own.</li>
<li>Send proper HTTP headers in responses to clients.</li>
<li>Corrected Content-Length: header in admin (raw) requests. Thanks to paluh for reporting.</li>
<li>Escape log entries in access log</li>
<li>Fixed a memory leak. Lost headers of stream because of wrong ref counter in associated refbuf objects.</li>
<li>Avoid memory leak in <code>_parse_mount()</code> when <code>type</code>-attribute is set</li>
<li>Updated web interface to be XHTML compliant.</li>
<li>Removed <code>status2.xsl</code> from release. It was only a broken example file anyway.</li>
</ul>
<h4 id="known-issues-1">Known issues</h4>
<ul>
<li>Will crash if certain config tags are left empty</li>
</ul>
</div>
</div>
</div>
<div class="footer">
<p>Support icecast development at <a href="http://icecast.org">icecast.org</a></p>
</div>
</body>
</html>
\ No newline at end of file
This diff is collapsed.
This section contains information about the admin interface of Icecast. Through this interface the user can manipulate many server features. From it you can gather statistics, move listeners from one mountpoint to another, disconnect connected sources or listeners and many other activities. Each function is enumerated here as well as an example usage of the function.
Each of these functions requires HTTP authentication via the appropriate username and password. For mount-specific functions, you may use either the `<admin-username>` and `<admin-password>` specified in the Icecast config file, or the username and password specified for that mountpoint (if any). For general functions (not specific to a single mountpoint), you must use the admin username and password.
# Admin Functions (mount specific)
All these admin functions are mount specific in that they only apply to a particular mountpoint
(as opposed to applying to the entire server). Each of these functions requires a mountpoint to
be specified as input.
## Metadata Update
This function provides the ability for either a source client or any external program to update
the metadata information for a particular mountpoint.
Example:
`/admin/metadata?mount=/stream&mode=updinfo&song=ACDC+Back+In+Black`
## Fallback Update
This function provides the ability for either a source client or any external program to update the
“fallback mountpoint” for a particular mountpoint. Fallback mounts are those that are used in the even
of a source client disconnection. If a source client disconnects for some reason that all currently
connected clients are sent immediately to the fallback mountpoint.
Example:
`/admin/fallbacks?mount=/stream.ogg&fallback=/fallback.ogg`
## List Clients
This function lists all the clients currently connected to a specific mountpoint. The results are sent
back in XML form.
Example:
`/admin/listclients?mount=/stream.ogg`
## Move Clients (Listeners)
This function provides the ability to migrate currently connected listeners from one mountpoint to another.
This function requires 2 mountpoints to be passed in: mount (the *from* mountpoint) and destination
(the _to_ mountpoint). After processing this function all currently connected listeners on mount will
be connected to destination. Note that the destination mountpoint must exist and have a sounce client
already feeding it a stream.
Example:
`/admin/moveclients?mount=/stream.ogg&destination=/newstream.ogg`
## Kill Client (Listener)
This function provides the ability to disconnect a specific listener of a currently connected mountpoint.
Listeners are identified by a unique id that can be retrieved by via the “List Clients” admin function.
This id must be passed in to the request via the variable `id`. After processing this request, the listener will no longer be
connected to the mountpoint.
Example:
`/admin/killclient?mount=/mystream.ogg&id=21`
## Kill Source
This function will provide the ability to disconnect a specific mountpoint from the server. The mountpoint
to be disconnected is specified via the variable `mount`.
Example:
`/admin/killsource?mount=/mystream.ogg`
# Admin Functions (general)
## Stats
The stats function provides the ability to query the internal statistics kept by the Icecast server.
Almost all information about the internal workings of the server such as the mountpoints connected,
how many client requests have been served, how many listeners for each mountpoint, etc. are available
via this admin function.
Example:
`/admin/stats`
## List Mounts
The list mounts function provides the ability to view all the currently connected mountpoints.
Example:
`/admin/listmounts`
# Web-Based Admin Interface
As an alternative to manually invoking these URLs, there is a web-based admin interface.
This interface provides the same functions that were identified and described above but presents them in
a nicer way. The web-based admin Interface to Icecast is shipped with Icecast provided in the
`admin` directory and comes ready to use.
The main path for the Web-Based Admin Interface is:
`/admin/stats.xsl`
## Advanced
The web-based admin interface is a series of XSL-Transform files which are used to display all the XML obtained
via the URL admin interface. This can be changed and modified to suit the user's need. Knowledge of
XSLT and transformations from XML to HTML are required in order to make changes to these scripts.
__Modification of existing XSLT transforms in `/admin` is allowed, but new files cannot be created here.__
Creation of new XSLT transforms as well as modification of existing transforms is allowed in the `/web` directory.
These work using the document returned by the `/admin/stats` endpoint.
To see the XML document that is applied to each admin XSLT, just remove the .xsl in your request
(i.e. `/admin/listclients`). You can then code your XSL transform accordingly.
\ No newline at end of file
This diff is collapsed.
# Basic Requirements
This section will describe the essential requirements in setting up a simple Internet radio station. It is by no means a complete list but should give you enough to get started. Please also note that those are generic instructions. If you installed a Linux/Unix distribution package, then it will likely come with different paths, different means of starting it, etc. In that case please also refer to the documentation of that distribution and or a distribution specific How-To.
As already explained in the Introduction, there are two major components involved: The streaming server (Icecast in this case) and the source client.
The following diagram shows how Icecast works:
![Icecast Shema Diagram](img/Icecast_shema.svg)
A Source Client (i.e. IceS, RoarAudio, …) connects to a mountpoint on the Icecast server and sends audio or video data to it. Listeners connect to the mountpoint and Icecast send the stream to them.
The Icecast server will be the place where all listeners of your stream will connect. The source client (in general) runs on a separate machine than Icecast, but does not necessarily need to.
# The Basics
Each Icecast server can house multiple streams, we call these mountpoints. A mountpoint is a unique name on your server identifying a particular stream - it looks like a filename, such as /stream.ogg and a listener can only listen to a single mountpoint at a time. This means you can have a single Icecast server contain multiple broadcasts with different content, or possibly the same broadcast but with streams of different bitrates or qualities. In this case each broadcast or stream is a separate mountpoint.
# Setting up Icecast
At this point, the steps outlined here related to the Unix version or Win32 console version of Icecast. Icecast is also available in a Win32 GUI version, and the steps are similar in setup, but not quite the same.
The first step in the process is to install the Icecast server itself. The recommended way to do this is using the distro packages, or in case of Win32 download the binary package or installer. How to do this is not contained within this documentation.
After installation there is placed a sample config file named `icecast.xml` in either `/usr/local/etc`, `/etc/` or `/etc/icecast2/` (for UNIX) or in the current working directory, in a folder called `etc`, in case you are using the Window binary package.
The next step is to edit the `icecast.xml` config file and set the appropriate values. Most of the specified values in the samples are fine, for a basic setup the following entries should be specified, and if neccessary, changed to suite your situation:
`<hostname>` - DNS name or IP address used for stream directory listings.
`<source-password>` - Will be used for the source client authentication.
`<admin-password>` - Will be used for authenticating admin features of Icecast.
`<listen-socket>` (both port and bind-address)
If you expect many listeners, make sure to adjust the `<clients>` limit in the `<limits>` block.
Additionally make sure to note where the Icecast log file is stored, see the `<logdir>` value in the `<paths>` section.
Once the configuration file is modified, you should be able to start the server with the following command
icecast -c /path/to/icecast.xml
If no error messages are generated, then check the `error.log` file in the log directory for the ‘server started’ message, it will look something like:
[2014-11-20 19:17:48] INFO main/main Icecast 2.4.1 server started
You may notice slight variations to the line above, but the key thing here is that the server is started, logging is working and the version is shown.
You can also verify that Icecast is started by visiting the following URL [http://localhost:8000/admin/stats.xsl](http://localhost:8000/admin/stats.xsl) on the machine running Icecast. Replace localhost with the correct hostname and adjust the port, if you aren't using the default port 8000.
You should be prompted for a username and password. Enter the username `admin` and the password you entered for `<admin-password>` in the config. If all is well, you should see a Status Page which represents Icecast statistics (more about that later).
# Setting up the Source Client
Now that the Icecast server is started you must configure your source client. The information you will need for the source client is the following:
- Hostname (or IP address) and port of the Icecast server - both of these come from `<listen-socket>`
- Source password - from `<source-password>`
Additionally, you will need to choose a mountpoint and specify this in the source client. Icecast does not need to know about each mountpoint (although you can configure settings for specific mountpoint, this is covered on Advanced configuration), however some points to mention regarding mountpoints:
All Ogg Vorbis streams should have mountpoints that end in .ogg (i.e. /mystream.ogg). This is due to the lazy way most media players infer the type of stream.
MP3 streams usually do not contain an extension (/mystream). Mount points also should not contain any spaces or odd characters (again due to the lazy way many of the media players are coded).
Once you have configured your source client, you should be able to connect it to the Icecast server. Verify that it is connected by hitting the stats.xsl URL that was mentioned above.
Now that you have the source connnected, listening to the stream involves simply opening the appropriate following URL in a browser:
http://yourip:port/mounpoint-you-specified
So for instance, if you attached your source client to an Icecast server located at 192.0.2.23:8000 with a mountpoint of /mystream.ogg, then you would open `http://192.0.2.23:8000/mystream.ogg` within your media player.
Alternatively you can use `http://192.0.2.23:8000/mystream.ogg.m3u`, (note the .m3u extension added) which will serve up a link that opens most media players. It is important to note that m3u need not contain only MP3 stream, it can contain streams of arbitrary content-type and is used by Icecast to serve a playlist that represents your broadcast to listening clients.
This diff is collapsed.
This source diff could not be displayed because it is too large. You can view the blob instead.
# Icecast 2.4.1 Documentation
Icecast is a streaming media server which currently supports Ogg Vorbis and MP3 audio streams.
It can be used to create an Internet radio station or a privately running jukebox and many
things in between. It is very versatile in that new formats can be added relatively easily
and supports open standards for commuincation and interaction.
Icecast is distributed under the GNU GPL, version 2. A copy of this license is included with
this software in the COPYING file.
There are two major parts to most streaming media servers: The component providing the
content (what we call source clients) and the component which is responsible for serving that
content to listeners (this is the function of Icecast).
# Prerequisites
Icecast requires the following packages:
* [libxml2](http://xmlsoft.org/downloads.html)
* [libxslt](http://xmlsoft.org/XSLT/downloads.html)
* [curl](http://curl.haxx.se/download.html) Version >= 7.10
* [libogg/libvorbis](http://www.vorbis.com/files) Version >= 1.0
* [OpenSSL](https://www.openssl.org/source/) (Optional, enable if SSL support is desired)