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

I looked at these requests and started trying to interpret the data of 
the header and the stream. I receive a header, and even when I added the 
parameter to the request to try and get meta-data, it seems that it is 
not being included. Namely, the number that is supposed to tell the 
distance between each meta-data section that is sent in the stream. I 
couldn't figure out the config setting for relaying meta-data with my 
icecast stream.

When I look at the stream, I also noticed that it says Oggs twice. Which 
one of these starts the stream? So what information is really important 
from the header, and is any of that actually important for decoding? How 
Can I find the first part of the stream that needs to be passed to 
Libogg, and does libogg or (libvorbis) have a feature that will callback 
when it reads meta data.

Best,
Andy S. Martin

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

On 10/3/13 5:04 PM, Brad Isbell wrote:
> The headers you get back are just an HTTP response.  When you get to 
> the actual data part of the message (where you see Oggs) that's the 
> data you send off to libogg to decode.
>
> You will need to remove metadata from the response periodically.  See 
> my posts here for more info:
>
> http://stackoverflow.com/a/6072488/362536
> http://stackoverflow.com/a/4914538/362536
>
>
> 	*Brad Isbell // AudioPump*
> brad at audiopump.co <mailto:brad at audiopump.co>
> Skype: bradisbell
> Phone: +1 312-488-4680
>
>
>
> On Thu, Oct 3, 2013 at 5:44 PM, Andy Martin <zippo227 at gmail.com 
> <mailto:zippo227 at gmail.com>> 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?
>
>     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
>
>
>     _______________________________________________
>     Icecast-dev mailing list
>     Icecast-dev at xiph.org <mailto:Icecast-dev at xiph.org>
>     http://lists.xiph.org/mailman/listinfo/icecast-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast-dev/attachments/20131004/e27feb1a/attachment.htm

Hi,

On 10/04/2013 06:27 PM, Andy Martin wrote:
> I looked at these requests and started trying to interpret the data of
> the header and the stream. I receive a header, and even when I added
> the parameter to the request to try and get meta-data, it seems that
> it is not being included. Namely, the number that is supposed to tell
> the distance between each meta-data section that is sent in the
> stream. I couldn't figure out the config setting for relaying
> meta-data with my icecast stream.
You're talking about legacy ICY things. Ogg, as Philipp explained has
the metadata inside, not piggybacked into the raw data.
So to get the metadata for an ogg stream you have to use the libraries.
If you're dealing with Icecast streaming an unsupported/legacy format
(yes that includes mp3), then you need to signal capability to extract
injected metadata to the server and then remove it from the stream
before you hand it over to a demuxer/decoder.
> When I look at the stream, I also noticed that it says Oggs twice.
> Which one of these starts the stream? So what information is really
> important from the header, and is any of that actually important for
> decoding? How Can I find the first part of the stream that needs to be
> passed to Libogg, and does libogg or (libvorbis) have a feature that
> will callback when it reads meta data.
I'd hope, that libogg has some documentation.
Generally everything after HTTP headers can be passed to the demuxer.
If you see a second Oggs, that might be another chain element starting.
Please note that ogg streams are often chained. This is actually how
you'll usually get metadata updates, there is a new chain element and it
has new metadata.

Hope that helps

Thomas

> On 10/3/13 5:04 PM, Brad Isbell wrote:
>> The headers you get back are just an HTTP response.  When you get to
>> the actual data part of the message (where you see Oggs) that's the
>> data you send off to libogg to decode.
>>
>> You will need to remove metadata from the response periodically.  See
>> my posts here for more info:
>>
>> http://stackoverflow.com/a/6072488/362536
>> http://stackoverflow.com/a/4914538/362536
>>
>>
>> 	*Brad Isbell // AudioPump*
>> brad at audiopump.co <mailto:brad at audiopump.co>
>> Skype: bradisbell
>> Phone: +1 312-488-4680
>>
>>
>>
>> On Thu, Oct 3, 2013 at 5:44 PM, Andy Martin <zippo227 at gmail.com
>> <mailto:zippo227 at gmail.com>> 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?
>>
>>     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
>>
>>
>>     _______________________________________________
>>     Icecast-dev mailing list
>>     Icecast-dev at xiph.org <mailto:Icecast-dev at xiph.org>
>>     http://lists.xiph.org/mailman/listinfo/icecast-dev
>>
>>
>
>
>
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev

reflum,

On Fri, 2013-10-04 at 19:04 +0000, "Thomas B. R?cker"
wrote:
> Hi,
> 
> On 10/04/2013 06:27 PM, Andy Martin wrote:
> > I looked at these requests and started trying to interpret the data
> of
> > the header and the stream. I receive a header, and even when I added
> > the parameter to the request to try and get meta-data, it seems that
> > it is not being included. Namely, the number that is supposed to
> tell
> > the distance between each meta-data section that is sent in the
> > stream. I couldn't figure out the config setting for relaying
> > meta-data with my icecast stream.
> 
> You're talking about legacy ICY things. Ogg, as Philipp explained has
> the metadata inside, not piggybacked into the raw data.
> So to get the metadata for an ogg stream you have to use the
> libraries.
> If you're dealing with Icecast streaming an unsupported/legacy format
> (yes that includes mp3), then you need to signal capability to extract
> injected metadata to the server and then remove it from the stream
> before you hand it over to a demuxer/decoder.
> 
> > When I look at the stream, I also noticed that it says Oggs twice.
> > Which one of these starts the stream? So what information is really
> > important from the header, and is any of that actually important for
> > decoding? How Can I find the first part of the stream that needs to
> be
> > passed to Libogg, and does libogg or (libvorbis) have a feature that
> > will callback when it reads meta data.
> 
> I'd hope, that libogg has some documentation.
> Generally everything after HTTP headers can be passed to the demuxer.
> If you see a second Oggs, that might be another chain element
> starting.
Litte correction on this:
'OggS' is the magic numer of the Ogg Pages. You will see it at the begin
of each page. If you want to know about the chaining you need to look at
the EOS and BOS flags.

libogg has a good interface to this, however another more hi-level API
may also tell you about this. E.g. libvorbis file will pass the serial
to you of the decodec audio segment it passed to you. If there is a new
stream (chain element) meta data is always updated so you just need to
look for that event.

I'm not suggesting to use libvorbisfile here. (I don't know too less
about the application to suggest anything.) If libvorbisfile is used I
recommend to have a look at the examples/. They will tell how to handle
chained streams.
> Please note that ogg streams are often chained. This is actually how
> you'll usually get metadata updates, there is a new chain element and
> it has new metadata.
This is very important: There are just too much broken players not
handling chaining correctly. It's part of the core spec and *really*
should be handled correctly (which is very easy normally).

> Hope that helps
same :)

-- 
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/20131007/ea1a479b/attachment.pgp