[icecast-dev] Work on ICECAST : IcecastAdmin, remodularisation, Doc (Docbook), speex ...

[Arnaud Ebalard]

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 at 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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.