Problem in iPhone streaming

[Pavol Grešša]

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-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev

[Romain Beauxis-2]

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

_______________________________________________
Icecast-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev

[Michael Smith-59]

On Thu, Nov 13, 2008 at 1:08 AM, Pavol Grešša <pavol.gressa@...> 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
_______________________________________________
Icecast-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev

[Thomas B. Ruecker-2]

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
_______________________________________________
Icecast-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev