Icecast dev - Oct 2013 - understanding icecast decoding from a listener client perspective

I want to write an icecast listener client using C# and C++. I can 
asynchronously connect read the continuous bytes from the stream using 
some basic C# code. When I look at the bytes (interpreted as ASCII) I 
don't understand what it is that I need to be using before passing the 
Ogg to libogg. I see some artist information, and I know that there is 
an ICY200OK type of message. I also see the word Oggs at the beginning. 
But, what do I really need to do to decode the stream and the header? 
What parts of the header are actually necessary for libogg to start 
pulling the packets?

Ideally, my client would connect to the stream and read the header as 
well as detect track information that is included in the icecast 
periodically.

The documentation that I've been reading for Icecast only explains the 
server and source client side. I've been working with icecast for a 
little over a year now, and I have had to resort to commercial products 
for decoding and playing a stream. I want to include this capability in 
my project without having to ask people to use Winamp or some other 
player. I  want to find the documentation on how to read the stream; how 
to interpret the periodic meta-data; how to pack these bytes into 
something usable for libogg. I'm very new to this concept of pages and 
packets.

Thank you in advance for reading this request.
-- 

Best,
Andy S. Martin

www.guitarrpg.com  <http://www.guitarrpg.com>
M.S. Computer Science Game Development
University of Southern California '2013 Alumni

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast-dev/attachments/20131003/db53c73c/attachment.htm

reflum,

On Thu, 2013-10-03 at 15:44 -0700, Andy Martin wrote:
> I want to write an icecast listener client using C# and C++. I can
> asynchronously connect read the continuous bytes from the stream using
> some basic C# code. When I look at the bytes (interpreted as ASCII) I
> don't understand what it is that I need to be using before passing the
> Ogg to libogg. I see some artist information, and I know that there is
> an ICY200OK type of message. I also see the word Oggs at the
> beginning. But, what do I really need to do to decode the stream and
> the header? What parts of the header are actually necessary for libogg
> to start pulling the packets? 
Icecast is just an HTTP server from the client perspective.
You ask it for the given resource and it will respond with a normal HTTP
reply. That includes the HTTP Header and the data.
From whyt ou write I guess you already handle the HTTP part correctly.
The rest is the data. In case of Ogg (see Content-type) it will start
with 'OggS'.

All of this http body part is just plain Ogg and passed to libogg.

> Ideally, my client would connect to the stream and read the header as
> well as detect track information that is included in the icecast
> periodically.  
The track information are stored within the codec's header two layers
deeper in the stack. (HTTP -> Ogg -> Codec).

For Ogg streams they are updated inline *when* needed. Also for all
common codecs within Ogg they are updated *sample accurate*.
The decoding library (e.g. libvorbis) will handle this.

> The documentation that I've been reading for Icecast only explains the
> server and source client side. I've been working with icecast for a
> little over a year now, and I have had to resort to commercial
> products for decoding and playing a stream. I want to include this
> capability in my project without having to ask people to use Winamp or
> some other player. I  want to find the documentation on how to read
> the stream; how to interpret the periodic meta-data; how to pack these
> bytes into something usable for libogg. I'm very new to this concept
> of pages and packets.
Hope my answer helped you. In general just consider it a plain Ogg file
as you would read it from disk. The only diffrence is that you read it
from HTTP. This also means that dumping the stream with *any* HTTP
client (e.g. wget) to disk will result in a valid and complet copy of
the stream.

> Thank you in advance for reading this request.
You are wellcome.

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url :
http://lists.xiph.org/pipermail/icecast-dev/attachments/20131004/e29ffe53/attachment.pgp