Hi, <p>I was streaming Ogg Vorbis to a mount point which didn't end .ogg ogg123 played the stream without any problems, but other clients (xmms, Audion) just kept rebuffering and failed to detect that it as an Ogg encoded stream. Surely the client should use the MIME type provided by the server rather than rely on the suffix in a URL ? <p>Is there any attempt to encourage clients to be more standard ? <p>Cheers, nick. --- >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, 2003-12-08 at 10:00, Nicholas Humfrey wrote:> ogg123 played the stream without any problems, but other clients > (xmms, Audion) just kept rebuffering and failed to detect that it as > an Ogg encoded stream. > > Surely the client should use the MIME type provided by the server > rather than rely on the suffix in a URL ?Just FYI: ogg123 actually uses the maximally paranoid scheme of using looking at the first couple dozen bytes of the stream to determine the file type, ignoring both the file extension and the MIME type, just in case the web server isn't sending correct or helpful content types. I do agree with you that players should not rely upon file extensions for format detection. (Note: This is not to say that file launchers, like Explorer, shouldn't rely on file extensions. I make no comment on that long-standing flamefest here.) --- Stan Seibert <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.
> 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.
On Tuesday 09 December 2003 03:00, Nicholas Humfrey wrote:> Hi, > > > I was streaming Ogg Vorbis to a mount point which didn't end .ogg > > ogg123 played the stream without any problems, but other clients > (xmms, Audion) just kept rebuffering and failed to detect that it as > an Ogg encoded stream. > > Surely the client should use the MIME type provided by the server > rather than rely on the suffix in a URL ?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.> > > Is there any attempt to encourage clients to be more standard ?<p>We'd really, really, like to. The problems are generally very deep, though - and we don't have the resources to lobby everyone. We'd welcome people going and complaining to the creators of their favourite buggy audio players, though :-) 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-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.