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 embeddedI'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 theHere'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.
> So here is the thing: I am trying to build an mp3 player in Macromedia Flash > that would work with Icecast. Using Flash as a mp3 player instead of Winamp, > XMMS...Well, I'm glad someone else besides me is interested on playing streams with mp3 files. I've made some tests and had the same problems you have. After some brawling I found that if you resolve to use icecast 1.3 instead of the newer 2.0, the problem vanishes. Actually I'm using icecast 1.3 to stream live audio events and play them on my web page with a little flash movie (I have a stream active right on this moment), but I'm still hoping to find a way to use icecast 2.0. fell free to ask if you have questions or need help on your tests. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> 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.This is correct: we send a user-agent header (for compatibility with shoutcast when doing relaying), but the only thing we do with that header is report it when requested (including logging).> 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.I believe he said he tried it with icecast 1.x and it worked - this is very strange, to say the least. Without detailed network dumps, it's hard to even guess at what might be being done differently. Mike --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hello everybody,
This topic was already published in the icecast development list but it did
not interest many people there because it is related to Macromedia Flash and
apparently all the development team is running Linux PPC (the flash plugin
is not available for Linux PPC). For this reason, I was advised to transfer
this topic to this regular icecast list.
Sorry for those who subscribed to both icecast and icecast-dev lists; you
will receive two times this message.
So here is the thing: I am trying to build an mp3 player in Macromedia Flash
that would work with Icecast. Using Flash as a mp3 player instead of Winamp,
XMMS,. could democratize Icecast because the Flash plugin is
cross-platform/cross-browser, it is installed on almost every computer
connected to the internet (Windows, MAC, Linux - but NOT linux PPC) and it
will be embedded into a webpage.
I successfully imported an Icecast live stream into Flash with this simple
ActionScript code:
TestIcecast = new Sound();
TestIcecast.loadSound("http://myradio.com:8000/mystream", true);
TestIcecast.start(0,0)
For those who don't know flash, here is the process of creating a flash
animation: you edit the code into a .fla file, then export this code into a
.swf file (the flash animation) and then embed this flash animation into a
webpage.
HERE IS THE PROBLEM: the code above works perfectly in a standalone swf file
but not when the swf is embedded into a webpage.
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 "-".
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
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
php script into my flash animation instead of the direct source URL (this
test was realized with the swf embedded):
192.168.0.5 - - [27/Nov/2003:04:54:03 Romance Standard Time] "GET /mystream
HTTP/1.1" 200 94383 "(null)" "-" 4549088
You can notice that it creates the exact same log if I use the php or the
direct stream source when I test my swf embedded.
Is there any header information missing in my php script? What header
information do I have to add in order to send the
"http://192.168.0.4:37/mystream" information (instead of
"-") that appears
after "(null)" into the ACCESS log (mentioned above)? Do you think the
problem might come from the macromedia Flash player's security policy? Note
that the same problem happens with Shoutcast.
Thank you very much for any help!
MAX
<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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
Ciao Assorgia, Anch'io sono felice che cè un'altra persona che cerca di importare uno stream di Icecast nel Flash! Just one easy question (I'm speaking English for the list), is there a real quality of sound difference between Icecast1 and 2? Is Icecast2 really more reliable? Can you provide a link to your webradio, I'd be glad to listen to it. Grazie, MAX -----Original Message----- From: owner-icecast@xiph.org [mailto:owner-icecast@xiph.org] On Behalf Of assorgia@tin.it Sent: Sunday, November 30, 2003 6:58 PM To: icecast@xiph.org Subject: Re: [icecast] Icecast in Macromedia Flash> So here is the thing: I am trying to build an mp3 player in MacromediaFlash> that would work with Icecast. Using Flash as a mp3 player instead ofWinamp,> XMMS...Well, I'm glad someone else besides me is interested on playing streams with mp3 files. I've made some tests and had the same problems you have. After some brawling I found that if you resolve to use icecast 1.3 instead of the newer 2.0, the problem vanishes. Actually I'm using icecast 1.3 to stream live audio events and play them on my web page with a little flash movie (I have a stream active right on this moment), but I'm still hoping to find a way to use icecast 2.0. fell free to ask if you have questions or need help on your tests. --- >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@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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@xiph.org [mailto:owner-icecast@xiph.org] On Behalf Of Leo Currie Sent: Monday, December 01, 2003 12:23 PM To: icecast@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 swffile> 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 itdoesn't> play anything). Anyway, I noticed the only difference between the twoACCESS> 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 becauseI> think my Flash animation doesn't send any header information when embeddedI'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 theHere'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@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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hi, is this some flash player you coded by yourself? Is it possible to download that player somewhere? Thanx... Am 30 Nov 2003 um 18:58 hat assorgia@tin.it geschrieben:> Actually I'm using icecast 1.3 to stream live audio events and play > them on my web page with a little flash movie (I have a stream active > right on this moment), but I'm still hoping to find a way to use icecast > 2.0.-- CU und wech... Daniel This is Linux Country. If you listen carefully, you can hear Windows reboot. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.