[icecast-dev] bug report w.r.t. streaming of metadata in icecast

[Brendan Cully]

On Friday, 10 August 2001 at 15:14, Richard Fromm wrote:
> On Fri, 10 Aug 2001, Brendan Cully wrote:
> 
> > The server returns an icy-metaint header which tells where the info
> > will be inserted. If, say, it's 4096 then you'll find the metadata
> > after every 4096 bytes of MP3 data.
> 
> that's what i originally thought was supposed to happen, which is why i
> sent the original mail with a bug report, saying i was expecting periodic
> insertion of metadata (icy-metaint was what i assumed indicated how
> often), but what was really happening was that the data got inserted once
> (or sometimes zero times, as per what you say and indeed sounds like an
> ices bug, not an icecast bug).
> 
> i just want to clarify, though -- it does *not* get periodically inserted
> every 4096 bytes (in this instance), and that is the intention.  it will
> get inserted once on some 4096 byte boundary, whenever a new client
> connects to the server.  and it will get reinserted once for any new
> client.  and it will also get reinserted whenever the source tells
> icecast to update the metadata, which is typically when it switches to 
> a new song.  yes?
> 
> sorry if i'm taking up so much e-mail on what once i understand it is i
> think a reasonably simple issue.

There are updates every interval. Please notice the 'justnull'
variable. Apparently you haven't fully understood the format of the
metadata: the first byte of metadata is a length byte. Multiply it by
16 to determine how much text to extract from the stream as
metadata. If the first byte is null, then you extract 0 bytes and
continue to use the metadata you already have. Every 4096 bytes you
either get new metadata if the udpseqnr doesn't match between source
and client, or you get a 'null' length byte. You can't just omit the
data without causing skipping problems - valid mp3 data would be
interpreted as a length byte and that amount of data would be removed
from the stream.

This should have been clear from inspection of the code. That and some
hexdumping was how I came to understand the protocol. By the way this
is the shoutcast protocol, painfully reverse-engineered by the icecast
team. You may blame nullsoft for the lack of documentation.

-Brendan

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