Icecast dev - Aug 2004 - bug report w.r.t. streaming of metadata in icecast

On Thursday, 09 August 2001 at 18:08, Richard Fromm
wrote:
> On Tue, 7 Aug 2001, Richard Fromm wrote:
> 
> > to clarify, the behavior that i saw was that most of the time the
title
> > streaming appeared in the client, but sometimes it did not.
> 
> i think i've nailed this down.  the problem is if the icecast server
> starts in the middle of a song already being sourced to it.  (which you
> can get by starting icecast, start ices, then shutdown and restart icecast
> and ices won't complain if a small amount of time passes)
Ok, that's an ices bug. Ices should make sure to resend the metadata
if it has to reconnect. I'll fix that soon.
> one related question -- is there any easy way to find where the metadata
> gets inserted into the stream, or do i basically have to continually parse
> the stream if i want to extract that info?  i'm seeing chunks of 4096
> bytes, and the metadata gets added at the end of some chunk.  but this
> doesn't necessarily correspond to a boundary between mp3 frames.  given
an
> mp3 stream, once i found a frame boundary it's easy to keep finding
those
> boundaries.  but i don't know how to arbitrarily find icecast chunk
> boundaries if there's no delineating information.
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. Unfortunately it does not position
itself on frame boundaries.

-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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

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?

orry if i'm taking up so much e-mail on what once i understand it is i
think a reasonably simple issue.

- rich

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.