[icecast] Icecast in Macromedia Flash

Macsym macsym69 at yahoo.fr
Mon Dec 1 14:56:09 UTC 2003



Hi Leo,

Like you, I know think the problem doesn't come from the headers with
Icecast. Shoutcast needs some header information before accepting to send
the stream but not Icecast. The flash animation doesn't work with Icecast
either. I tried adding the mp3 extension to my live stream and to serve a
static mp3 through Icecast but I had the same results. Serving a static mp3
through apache works perfectly, even in embedded mode. By analyzing the
logs, I noticed the animation, even when embedded, could access the stream
and Icecast, actually sends the stream to the player but it doesn't play
anything. The standalone player and the flash plugin (needed to run an
embedded animation) are exactly the same. However, the standalone player
doesn't have all security features that the plugin has. I guess the plugin
can't play the stream for security reasons: there might be a cross-domain
issue, or the plugin consider the mp3 is corrupted because it is streamed. I
am now reading all papers I got about flash security. I tried to apply all
solutions advised by macromedia but it still doesn't work for the moment.
I did all tests with a 58k bit rate but I'll now try to import a 24K bit
rate
Thanks for advising,

MAX
-----Original Message-----
From: owner-icecast at xiph.org [mailto:owner-icecast at xiph.org] On Behalf Of
Leo Currie
Sent: Monday, December 01, 2003 12:23 PM
To: icecast at xiph.org
Subject: Re: [icecast] Icecast in Macromedia Flash

Hi -

Ok, I don't pretend to have answers for you, sorry, but here are some 
thoughts:

[snip]

> HERE IS THE PROBLEM: the code above works perfectly in a standalone swf
file
> but not when the swf is embedded into a webpage.

So you have to assume that there is some difference between the embedded 
player and the standalone player.

<p>> 
> I analyzed the logs of my icecast server to understand what is happening:
> 
> When I run the swf in standalone mode (not embedded), the ACCESS log is:
> 192.168.0.3 - - [27/Nov/2003:04:37:46 Romance Standard Time] "GET
/mystream
> HTTP/1.1" 200 246535 "(null)" "http://192.168.0.4:37/mystream" 13712368.
> 
> When I run the webpage in which the swf is embedded in, I can see the swf
> contacts the server but no stream is played. The ACCESS log is:
> 192.168.0.3 - - [27/Nov/2003:04:42:58 Romance Standard Time] "GET
/mystream
> HTTP/1.1" 200 328981 "(null)" "-" 13712464
> 
> I both case, the ERROR log is:
> [.]Client connected
> [.]Source found for client
> [.[Client added
> 
> It means the swf, even when embedded, can access the stream (but it
doesn't
> play anything). Anyway, I noticed the only difference between the two
ACCESS
> logs is the "http://192.168.0.4:37/mystream" (in first log) instead of "-"
> (in second log) that appears behind "(null)". Please not that I made other
> tests with Winamp and the habitual information that appears behind
"(null)"
> is "-".

Ok, but this isn't really significant.
The first version (standalone) is reporting the referring address, the 
second isn't. Also, for some reason, the user-agent reported the first 
time is the stream address, but this won't affect anything.

> 
> I thought the problem might come from the headers that Icecast need to
> receive from regular players (Winamp,.) before sending the stream because
I
> think my Flash animation doesn't send any header information when embedded

I'm sure Icecast (unlike Shoutcast) doesn't care what user-agent string 
is provided. If the stand-alone player works without modified headers, 
this can't be the problem.

> into a webpage (headers information is send by the browser instead). For
> this reason I tried to use a php script that sends hardcoded header
> information (Content-type: audio/mpeg; GET <path of the stream> HTTP/1.1;
> protocol: \"http\") to the server. Then I call the URL of this script into
> my flash code instead of the URL of the stream. The php script is:
> <?php
> $streamname = "192.168.0.4"; // put in whatever stream you want to play 
> $port = "37"; // put in the port of the stream 
> $path = "/mystream"; // put in any extra path, this is usually just a / 
> header("Content-type: audio/mpeg"); 
> $sock = fsockopen($streamname,$port); 
> fputs($sock, "GET $path HTTP/1.1\n");
> fputs($sock, "protocol: \"http\"\n");
> fputs($sock, "Connection: close\n\n");
> fpassthru($sock);
> ?>
> I still have the same problem even with the script: I can listen to the
> stream when I run the swf in standalone mode but NOT when it is embedded
> into a webpage. I also analyzed the access logs of Icecast when I call the

Here's a thought.
Perhaps the embedded player is missing the relevant codec (MP3 decoder) 
to play the stream? Have you tried including a short, static MP3 at the 
start of the animation? My hopeful guess is that the embedded version is 
being 'compiled' without the MP3 decoder. If you force the encoder to be 
included (by adding a short static mp3 file at the start) it might know 
what to do with the stream once it gets it.
Maybe even simply adding '.mp3' to the end of the mountpoint name (do 
this in the source client configuration) will force it to work.

Of course, I'm probably completely wrong. Have you tried using the 
player to listen to Shoutcast streams? How about static mp3's served 
from Apache?
Or maybe there is a limitation in the embedded player on content 
bitrate? What if you use it to 'tune-in' to low bitrate servers?

Hope you get it working - I agree it would be nice to add Flash to the 
list of supported clients.

Leo

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

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



More information about the Icecast mailing list