Icecast dev - Aug 2004 - Work on ICECAST : IcecastAdmin, remodularisation, Doc (Docbook), speex ...

Hello,

3 months ago, we (a group of 8 students of the ENSEIRB engineering 
school (France))
started to work on icecast.

We decided to work on another CVS server. The aim _was not to fork a new 
version_
of Icecast : the idea was to clean the code as fast as possible in order 
for new
developers to enter the  sources in an easier way.

We mainly worked on format, sources, and tried to clearly separate the 
differents activities.

For Format module, the main idea was to open Icecast to new Ogg formats 
: there's now
a direct recognition of the encapsulated format (vorbis, speex, ...) 
when the stream has Ogg
mime type.
We develop an Ogg speex module (but no speex streamer => no tests for 
Ogg) and the
development for fLaC or Theora or other ogg encapsulated format should 
be easy.

About MP3 (not a free format, as you know), the rewriting  of the  
plugin  was  quite awful
because this format wasn't designed to be streamed.
We tried to test it but we were unable to use an icecast2 compatible MP3 
streamer (liveice,
shoutcast, darkice, ...)

We also modified the buffer structure in order to make the icecast work 
more logical :
just inserting the client in the stream and then serving him in a non 
specific way (avoiding
the reconstruction of data for each client).

We did intensive tests on Ogg vorbis after this work : ogg vorbis 
icecast2 streams can be
played with mplayer, ogg123, xmms.

Another part of our work was the documentation :
- The parts we touched were commented using *Doxygen* (see /doc/Doxyfile 
in the cvs tree)
- We rewrote a user documentation in Docbook format based on Pierre 
Amadio' s work.
- We wrote a developer documentation, also in *DocBook *format.
All these documentations were made in english (french english ;-)) and 
are in the cvs tree.

The last part of our work was the *administration.* 3 people worked on 
it trying to leave
the basis of an administration system.
It is now separated from the main icecast process but the idea was to 
develop it and test
it this way to later incorporate it in a thread in icecast. This service 
should allow user
to modify the icecast config file depending on his permission. Then, 
when merging in
the main icecast process, the config file could be reread to take these 
changes into account.
This administration module (*IcecastAdmin*) is based on *OpenSSL* : the 
user can use
his favourite browser to make changes.
An IcecastAdmin doc is available in the main icecast doc we wrote.

<p>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

*To see everything we did, checkout on savannah's cvs :
the project's name is "interopcast"

You can start on the savannah's homepage : http://savannah.nongnu.org
or on this page : 
http://savannah.nongnu.org/cgi-bin/viewcvs/interopcast/ENSEIRB/icecast/

Please, do a checkout on the cvs, watch our work
and let us know what you think about it !

*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

*
*Arnaud.*

<p>*ps : just to give our names and the tasks we did :
Administration work : Antoine Allombert, Mickaël Floc'hlay, Guillaume 
Leroux.
Remodularisation  work : Sébastien Henrio, Florian Pierron,  Denis 
Tessier,  Jérémy Vies  and me.
Doc : all of us.

<p><p><p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hello,
you're quite right, but as I wrote it in the mail, MP3 is not designed 
to be streamed and
the "shoutcast way" is (for me) not a good way to stream data :
- Generally, a first metadata packet is in the stream at the beginning 
of the song and then,
  after ICY-METADATA-INTERVAL bytes, there's a "0" which indicates
a
zero length
  metadata string. So the reconstruction of metadata is made just only 
for all this "zero"

- The aim of a streaming server is to serve clients by inserting them in 
the stream,
   not to reconstruct data for every client (Am I right?).

Because the icy-metadata-interval can be changed (I don't find this very 
useful, but ...)
in Icecast, we could lower it to solve the problem, based on the bitrate 
of the MP3 stream.

Anyway, I don't like MP3 (not free, technically weaker than Ogg vorbis 
and not as adequate
as Ogg for streaming).

So we decided to focus on Ogg kinds of streams : it seemed to be the 
main format of Icecast
and a big part of his interest.

Finally, for MP3, the data are preprocessed (metadata interval modified 
if wanted) and then
stored : there's no post processing done for every client. So you're 
right, there can be a few
seconds delay for the client (It would be better as I wrote to modify 
the interval depending on
the bitrate).

Another comment : 8kbps is not reasonable for a mid-quality stream in 
MP3 format (in speex,
Iwould agree but in MP3 ;-) )

<p>Hoping this answer can satisfy you

Arnaud.

Michael Smith wrote:
>>We also modified the buffer structure in order to make the icecast work
>>more logical :
>>just inserting the client in the stream and then serving him in a non
>>specific way (avoiding
>>the reconstruction of data for each client).
>>    
>>
>
>Can you explain what you mean by this? For ogg streaming, icecast2 does
_not_
>reconstruct data for each client. For mp3 streaming, it does - but only 
>because it _has to_ - if you don't, you have to artificially synchronise
on
>metadata interval. That would mean that for a low bitrate mp3 stream (say 
>around 8 kbps), it would be an average of 8 seconds between connecting and 
>the client being sent _any_ data at all. That's clearly not desirable,
so for
>mp3, we do rebuild the data stream on a per-client basis. 
>
>(I'm not ignoring the rest of your work, by the way - I just haven't
had a
>chance to look at it yet).
>
>Mike
>
>
>--- >8 ----
>List archives:  http://www.xiph.org/archives/
>icecast project homepage: http://www.icecast.org/
>To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
>containing only the word 'unsubscribe' in the body.  No subject is
needed.
>Unsubscribe messages sent to the list will be ignored/filtered.
>
>  
>
--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> We also modified the buffer structure in order to make the icecast work
> more logical :
> just inserting the client in the stream and then serving him in a non
> specific way (avoiding
> the reconstruction of data for each client).
Can you explain what you mean by this? For ogg streaming, icecast2 does _not_ 
reconstruct data for each client. For mp3 streaming, it does - but only 
because it _has to_ - if you don't, you have to artificially synchronise on 
metadata interval. That would mean that for a low bitrate mp3 stream (say 
around 8 kbps), it would be an average of 8 seconds between connecting and 
the client being sent _any_ data at all. That's clearly not desirable, so
for
mp3, we do rebuild the data stream on a per-client basis. 

(I'm not ignoring the rest of your work, by the way - I just haven't had
a
chance to look at it yet).

Mike

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.