[icecast] Icecast in Macromedia Flash
Leo Currie
leo.currie at strath.ac.uk
Mon Dec 1 11:23:21 UTC 2003
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.
More information about the Icecast
mailing list