Icecast - Aug 2004 - Icecast2 Ogg Clients

> They should. A large number of them are horribly broken (I don't know
about
> audion, but in the case of both xmms and winamp, the plugin API is designed
> such that the _plugin_ has to do the HTTP streaming itself - and the plugin
> has to decide whether to handle the play request _before_ it actually
starts
> the request. I believe this was fixed in winamp3, but winamp3 had many
other
> even more serious bugs that made streaming not work reliably at all.
It's even more broken than this.

In both XMMS and Winamp, the mp3 plugin will grab EVERYTHING except urls
that end in '.ogg'.  You can easily grep and find this code in the XMMS
plugin if you're curious.  So anything that doens't end in .ogg
won't
even be looked at, itwill be shipped off to the mp3 plugin which will
keep rebuffering trying to find valid data.  But all this happens in
such a way that the user can never know what is really going on.

To my knowledge, only RealNetwork's code does this the right way.

jack.
--- >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-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.

At 05:50 PM 12/8/2003 -0700, you wrote:
>It's even more broken than this.
>
>In both XMMS and Winamp, the mp3 plugin will grab EVERYTHING except urls
>that end in '.ogg'.  You can easily grep and find this code in the
XMMS
>plugin if you're curious.  So anything that doens't end in .ogg
won't
>even be looked at, itwill be shipped off to the mp3 plugin which will
>keep rebuffering trying to find valid data.  But all this happens in
>such a way that the user can never know what is really going on.
not to condone what the winamp mp3 input plugin has done, but as far as I 
know, the plugin actually only grabs .mp3 extentions and also urls without 
extensions.  So it's not entirely correct to say that the mp3 input plugin 
grabs everything except .ogg.  When winamp is told to play a file, it will 
pass the URL to each of the input plugins (via a call to the 
input-plugin-coded is_playable() function.  If the input plugin returns 1 
from this call, then that input plugin is invoked.  Now I'm not sure in 
which order the input plugins are called, but I thought the mp3 input was 
invoked last as a sort of catch-all "if nothing else matches, lets try to 
assume it's a mp3 stream/file...

although this is probably more than anyone wanted to know about the inner 
workings of winamp.

Winamp 3 did fix this by looking at Content-types, but for some reason was 
still horribly broken for vorbis streams.  It is unknown what technique 
Winamp 5 uses, but my guess is that it still uses the "extension
technique"
in order to support the existing 2.x input plugin architecture.

This is all educated conjecture however since I, nor anyone else outside 
Nullsoft and a few contractors under NDAs, have seen the code for Winamp's 
input plugins or plugin architecture... :)

oddsock

<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-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.

On Mon, 8 Dec 2003, oddsock wrote:
> Winamp 3 did fix this by looking at Content-types, but for some reason was
> still horribly broken for vorbis streams.
IIRC, the change from application/x-ogg to application/ogg broke Winamp 3
streaming and it never got fixed.

Geoff.

<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-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.