[Icecast-dev] understanding icecast decoding from a listener client perspective

[Philipp Schafft]

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