4

I'm trying to play mp3 shoutcast stream radio stations with HTML5 audio.

I don't think it will be relevant but here is the code anyway:

var player = new Audio();
player.autobuffer = true;
player.src = "http://173.192.48.71:9048/;";
player.volume = 1;
player.play();

Shoutcast detects that request comes from browser and returns radio status page, so I put ";" at the end of stream which forces server to return audio stream instead of status page. This works fine in Chrome and Safari, but not in Firefox.

Firefox for some reason detects this as text/plain content and refuses to play it with this error:

HTTP "Content-Type" of "text/plain" is not supported. 
Load of media resource http://173.192.48.71:9048/; failed.

I used Fiddler to inspect what is being sent from shoutcast server and it clearly states "content-type: audio/mpeg". Is there any way to force Firefox to play the shoutcast stream with HTML5 audio?

Jonas
  • 121,568
  • 97
  • 310
  • 388
Igor Jerosimić
  • 13,621
  • 6
  • 44
  • 53
  • Firefox does not generally support MP3. https://developer.mozilla.org/en-US/docs/HTML/Supported_media_formats Are you on a version that does? – Brad Jun 10 '13 at 00:58
  • @Brad MP3 is not supported natively, but it uses codec from OS. I tried playing non-shoutcast mp3 stream and it works, but for shoutcast it doesn't. I guess FF thinks that it's text/plain because of ICY's textual metadata header. – Igor Jerosimić Jun 10 '13 at 06:01
  • The `ICY-*` headers won't affect anything. The error message is either misreported, or there is a bug in your where somehow you are loading a different URL. (I doubt it is a bug, as if you hit any other endpoint on that server, you would get `text/html` instead.) – Brad Jun 10 '13 at 14:22
  • @Brad: This is a recent change to Mozilla that causes non-http content (HTTP/0.9) on non-standard ports to be forced to `text/plain` content-type, so yes, ICY headers make the world of difference here. See my answer below. – spender Jul 12 '13 at 14:50
  • @spender, `ICY` in the status line... yes, that makes sense. I was referring to the actual `ICY-MetaInt` headers and what not. – Brad Jul 12 '13 at 15:13

1 Answers1

3

Adobe Flash Player support for Shoutcast has broken twice (see here and here) in the last year, so this is a really important issue for me.

I decided to investigate.

Instead of using standard HTTP, Shoutcast uses ICY protocol, which is approximately the same as HTTP/1.0.

The status line that Shoutcast sends is

ICY 200 OK

but Mozilla doesn't understand the ICY part of this status line, so it assumes that the response is HTTP/0.9 (which has no content type/headers). The upshot of this is that the body of the stream includes the ICY status line and headers (i.e the headers are not parsed by Mozilla). Because there's no content-type, Mozilla does a bit of "media-sniffing" and discovers valid MP3 frames at a small offset into the content and the <audio> tag functions correctly using this sniffed content-type.

Now along comes an issue that gets fixed by forcing all HTTP/0.9 content coming over non-standard ports (i.e. non-port 80/443) to a content-type of text/plain. Now, when the content body is passed to the HTML <audio> tag it already has a content-type of text/plain, so it is no longer sniffed as it was prior to this issue, and instead Mozilla doesn't allow it to be played.

The good news is that I fixed this annoyance and Mozilla now treats ICY protocol as being equivalent to HTTP/1.0. This in turn means that Mozilla can decode the headers and read the correct content type audio/mpeg and playback is restored.

My fix should find its way into Mozilla24 later this year.

In the mean time, if you want to play Shoutcast in Mozilla, you'll need to broadcast over port 80.

spender
  • 117,338
  • 33
  • 229
  • 351