[icecast-dev] icecast2 ogg vorbis client request headers

[Dave St John]

That seems it may work, however the server adds the client (php proxy script
in this case)
and does not disconnect it, however winamp does not recieve any audio, just
sits there saying BUFFERING
I know its related to the amount of bytes read into the header or something
in that area
as my tests with shoutcast nsv resulted in the same fashion.

the main goal of this is for subscription authentication, sure you can use a
web based from to login
to a server, however it shows up in winamp or any other player for that
matter with the link to the server url and mount,
which leavs a vulneralbility for listeners to spread the server around to
other listeners etc....
When a php script is used, it shows up in winamp etc... as a link to a php
script and does not show the actual link to
server ip and port/mount.
Sure anyone can use netstat to get an incoming ip and port however netstat
doesnt reveal a mount point
and if the webcaster hides there status.xsl files or renames them to
something inconspicuous then it creates a nice
subscription based system (albeit not 100% hackable as its a frontend, but
very effective).

like i said i got the mp3 nailed down, ogg just needs work, Any help would
be appreciated and i can provide access to the members area for testing
as well as an icecast2 server.

<p>Dave St John
Mediacast1 Administration

Need Support ?
http://mediacast1.com/helpdesk
----- Original Message ----- 
From: "oddsock" <oddsock at oddsock.org>
To: <icecast-dev at xiph.org>
Sent: Thursday, April 01, 2004 9:37 PM
Subject: Re: [icecast-dev] icecast2 ogg vorbis client request headers

<p>> I imagine something to the effect of (a completely untested and hack-ish
> way to do it):
> $count = 0;
> while (!feof($sp)) {
>          $str = fread($sp,1);
>          if ($count == 0) {
>                  if ($str == "\r") {
>                          $count = 1;
>                          continue;
>                  }
>          }
>          if ($count == 1) {
>                  if ($str == "\n") {
>                          $count = 2;
>                          continue;
>                  }
>          }
>          if ($count == 2) {
>                  if ($str == "\r") {
>                          $count = 3;
>                          continue;
>                  }
>          }
>          if ($count == 3) {
>                  if ($str == "\n") {
>                          $count = 4;
>                          continue;
>                  }
>          }
>          if ($count == 4) {
>                  break;
>          }
> }
> // now your at the end of the header
> while (!feof($sp)) {
>          $str = fread($sp,4096);
>          // Write data (in $str to client (listener in this case) - not
> sure how you do this...
> }
>
> At 10:26 PM 4/1/2004, you wrote:
> >So instead set it from 4096 bytes to 0  and increment till it reaches the
> >end?
> >show me an example please.
> >
> >
> >Dave St John
> >Mediacast1 Administration
> >
> >Need Support ?
> >http://mediacast1.com/helpdesk
> >----- Original Message -----
> >From: "oddsock" <oddsock at oddsock.org>
> >To: <icecast-dev at xiph.org>
> >Sent: Thursday, April 01, 2004 9:15 PM
> >Subject: Re: [icecast-dev] icecast2 ogg vorbis client request headers
> >
> >
> > > At 08:54 PM 4/1/2004, you wrote:
> > > >Well the code itself is what i took from tom peppers sc proxy script
and
> > > >incorperated our own auth system for icecast2
> > > >i know i got it close with ogg and it seems to be when i tweak the
> > > >$str.=fread($sp,4096);
> > > >bit amount, i get different results, 4096 works fine for mp3 on
icecast2
> >and
> > > >shoutcast, but im assuimg maybe there is more or less to read from
> > > >the ogg headers?? if so what would be the correct amount?
> > >
> > > the correct amount would vary depending on what your http response
headers
> > > look like.
> > >
> > > don't read a flat 4096 amount, this will (as Mike said) most likely
read
> >in
> > > part of the vorbis headers, and since your throwing away this 4096
bytes,
> > > you are throwing away part of the vorbis headers, which are required
to be
> > > sent first in a vorbis stream.
> > >
> > > so instead of reading 4096, just read a byte at a time until you get a
> > > character series "\r\n\r\n"...then you know your at the end of the
http
> > > header and you won't be thowing away vorbis critical data..
> > >
> > > oddsock
> > >
> > >
> > > --- >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.
>
>
> --- >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.
>

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