Hi, i'm developing an internet radio client for iPhone and as server is used Icecast2. My problem is that every time when client connects to some source(mount) Icecast2 sends correct HTTP 1.0 header and after header delimiter(two empty lines(\r\n\r\n)) should be data ( mp3 samples). But every time in the first packet in the beginnig of data section there are some bytes to which iPhone audio parser cannot undestand( Becasue every mp3 sample starts with mp3 header (0xFFF) ). This happens only to first packet. I'm sure of that, because i have stream in what i'm sure that raw sound data begins with prefix 0xFFF3 and every time when i parse whole data in first packet and get only those mp3 sample, stream will became stable and iPhone is playing that radio for rest of time without any parsing. I'm debugging icecast source code for 2 days and i still did'n find function or procedure or whatever is it, where in start of client streaming icecast2 push in the begining , right after header, these bytes, which have everytime different lenght. I don't really know what is it. So please , can you help me locate source of this problem?
Le Thursday 13 November 2008 10:08:19 Pavol Gre??a, vous avez ?crit?:> Hi,Hi !> i'm developing an internet radio client for iPhone and as server is ? > used Icecast2. My problem is that every time when client connects to ? > some source(mount) Icecast2 sends correct HTTP 1.0 header and after ? > header delimiter(two empty lines(\r\n\r\n)) ?should be data ( mp3 ? > samples). But every time in the first packet in the beginnig of data ? > section there are some bytes to which iPhone audio parser cannot ? > undestand( Becasue every mp3 sample starts with mp3 header (0xFFF) ). ? > This happens only to first packet. I'm sure of that, because i have ? > stream in what i'm sure that raw sound data begins with prefix 0xFFF3 ? > and every time when i parse whole data in first packet and get only ? > those mp3 sample, stream will became stable and iPhone is playing that ? > radio for rest of time without any parsing. > > ? I'm debugging icecast source code for 2 days and i still did'n find ? > function or procedure or whatever is it, where in start of client ? > streaming icecast2 push in the begining , right after header, these ? > bytes, which have everytime different lenght. I don't really know what ? > is it. > > So please , can you help me locate source of this problem?Icecast doesn't do any modification on the streamed data in mp3, as far as I know, so you'll only get the stream at its current position, be it a mp3 header or not.. mp3 data may have a lot of garbage at its beginning, like id3 tags, LAME headers and so on.. Also, ICY metadata update, if you enabled it, will add metadata information at a regular byte rate, so you also have to seperate these data from the audio data. Hence, you should code an interface with the iPhone audio decoder that collects only audio data and send only this data to the decoder, starting with the first mp3 header it encounters.. Romain
On Thu, Nov 13, 2008 at 1:08 AM, Pavol Gre??a <pavol.gressa at ecommerce.cz> wrote:> Hi, > > i'm developing an internet radio client for iPhone and as server is > used Icecast2. My problem is that every time when client connects to > some source(mount) Icecast2 sends correct HTTP 1.0 header and after > header delimiter(two empty lines(\r\n\r\n)) should be data ( mp3 > samples). But every time in the first packet in the beginnig of data > section there are some bytes to which iPhone audio parser cannot > undestand( Becasue every mp3 sample starts with mp3 header (0xFFF) ). > This happens only to first packet. I'm sure of that, because i have > stream in what i'm sure that raw sound data begins with prefix 0xFFF3 > and every time when i parse whole data in first packet and get only > those mp3 sample, stream will became stable and iPhone is playing that > radio for rest of time without any parsing.Icecast doesn't support mp3 - it's a non-free format, and thus not something we really care about. However, it does pass through mp3 data from the source client - so for many cases, mp3 streaming works fine. Because it doesn't handle mp3 explicitly, the client gets started at an arbitrary byte offset - not at the start of an mp3 frame, generally. Most decoders find the next sync-point just fine, and then decode ok - perhaps the iphone doesn't. So what you're seeing is the expected behaviour. You could add explicit mp3 handling to your local copy to avoid this problem - you'd need to write an mp3 parser (pretty simple) and plug it in using the format-specific infrastructure in icecast. We wouldn't accept this change back upstream, of course, since mp3 is non-free. Mike
Pavol Gre??a schrieb:> Hi, > > i'm developing an internet radio client for iPhone and as server is > used Icecast2. My problem is that every time when client connects to > >I'd suggest to check the mailing-list archive for the icecast mailing list: "[Icecast] patch for native iphone support" 2008-08-25 01:48 Thomas