[icecast-dev] Work on ICECAST : IcecastAdmin, remodularisation, Doc (Docbook), speex ...
ebalard at enseirb.fr
Mon Jun 9 14:46:39 PDT 2003
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
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
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
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
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).
>--- >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.
More information about the Icecast-dev