Currently I am using a flash player to play my shoutcast stream. I would like people on mobile devices to be able to listen as well, and it seems HTML5 is the way to go. How would I go about getting this shoutcast stream "stardust.wavestreamer.com:3353" working in HTML5?
I tried using
but that does not seem to be compatible with shoutcast.
If you connect to a SHOUTcast server with a web browser, it will detect your browser because it has Mozilla in the User-Agent header, and send you to the admin page for the stream anyway. You can test this yourself by simply going to http://stardust.wavestreamer.com:3353/.
Fortunately, SHOUTcast servers provide a way to force the loading of the stream. Just add a semicolon ; to the end of the URL.
http://stardust.wavestreamer.com:3353/;
Internally in the SHOUTcast server, it will now see your User-Agent string as MPEG OVERRIDE, which no longer contains Mozilla, so you get the actual media stream.
Related
I'm looking for a dead-simple way to convert an RTMP stream (from an IP camera) into something I can use in the browser. Ideally this server would read from the rtmp:// URL of my camera, re-encode the stream, and then server the stream in a format I can use in a <video> tag on a web page.
However, my understanding is that HTML5 and the <video> tag does not support live streaming. Therefore, I'm left using HLS or DASH. My understanding is that HLS is supported by almost all devices (I only care about the Chrome browser on both my Linux desktop, and my Android device).
So what is the easiest way to convert from a rtmp:// stream to HLS? I've tried using the nginx-rtmp-module (https://github.com/ut0mt8/nginx-rtmp-module), but after re-compiling Nginx, I cannot get the configuration file to work correctly. I also run into the problem that my rtmp:// URL doesn't seem to fit the "standard" pattern of rtmp://localhost/$app/$name I see in most of the documentation. Mine looks like: rtmp://192.168.1.103:1935/flash/1:YWRtaW46YWRtaW4= where the last part is a the username and password (admin/admin) encoded in Base64.
Ultimately, I have multiple cameras, and I'm looking to make a simple page where I can display them all. What's the easiest way to go about this on Linux?
For those who might be searching for something similar, I was able to use ZoneMinder. It configures a server that does exactly what I want: convert an RTSP stream to something that can be displayed in the browser via an img tag. You can figure out the URL for the image source by simply inspecting the element in the browser.
The code for the ZoneMinder server is on GitHub: https://github.com/ZoneMinder/zoneminder It would be nice if one could easily extract just the server that translates RTSP into the image data, but the easiest way to get up-and-going was to simply configure the whole service.
My suggestion would be to use https://github.com/aler9/rtsp-simple-server. It fulfills your requirement of being “dead simple” and can convert from RTMP to HLS in about 2 to 10 lines of YAML config.
I'm trying to figure out if web based audio streaming sites use the Web Audio API for playback or if they rely on the audio element or something else.
Since the user of an audio streaming service typically doesn't need more functionality than starting and stopping the audio, then I guess that the audio element is enough. If a VU-meter is required then I would guess the Web Audio API would be used since it has an built in analyser node. But since IE doesn't support the API then I suppose you'd rather use the audio element and reach the IE users than using fancy extras such as an VU-meter.
I've been looking at the source code for Spotifys web player, Grooveshark, BBC radio and the Polish public radio but I find neither audio elements or use of the Web Audio API. I did find that the Swedish public radio (sr.se) makes use of the audio element though.
I'm not asking for anyone to go through the JavaScript source code for me, but rather if someone who is familiar with the subject could point me in the right direction.
I don't know of any internet radio services playing back their streams with the Web Audio API currently, but I wouldn't be surprised to find one. I've been working on one myself using Audiocog's excellent Aurora.js library, which enables codecs in-browser that wouldn't normally be available, by decoding the audio with JavaScript. However, for compatibility reasons as you have pointed out, this would be considered a bit experimental today.
Most internet radio stations use progressive HTTP streaming (SHOUTcast/Icecast style) which can be played back within an <audio> element or Flash. This works well but can be hard to get right, especially if you use SHOUTcast servers as they are not quite 100% compatible with HTTP, hurting browser support in some versions of Firefox and a lot of mobile browsers. I ended up writing my own server called AudioPump Server to get better browser and mobile browser support with HTTP progressive.
Depending on your Flash code and ActionScript version available, you might also have to deal with memory leaks in creative ways, since by default Flash will keep all of your stream data in memory indefinitely as it was never built to stream over HTTP. Many use RTMP with Flash (with Wowza or similar on the server), which Flash was built to stream with to get around this problem.
iOS supports HLS which is basically a collection of static files served by an HTTP server. The encoder writes a chunk of the stream to each file as the encoding occurs, and the client just downloads them and plays them back seamlessly. The benefit here is that the client can choose a bitrate to stream and, raising quality up and down as network conditions change. This also means that you can completely switch networks (say from WiFi to 3G) and still maintain the stream since chunks are downloaded independently and statelessly. Android "supports" HLS, but it is buggy. Safari is the only browser currently supporting HLS.
Compatibility detection is not something you need to solve yourself. There are many players, such as jPlayer and JW Player which wrangle HTML5 audio support detection, codec support detection, and provide a common API between playback for HTML5 audio and Flash. They also provide an optional UI if you want to get up and running quickly.
Finally, most stations do offer a link to allow you to play the stream in your own media player. This is done by linking to a playlist file (usually M3U or PLS) which is downloaded and often immediately opened (as configured by the user and their browser). The player software loads this playlist and then connects directly to the streaming server to begin playback. On Android, you simply link to the stream URL. It will detect the Content-Type response header, disconnect, and open its configured media player for playback. These days you have to hunt to find these direct links, but they are out there.
If you ever want to know what a station is using without digging around in their compiled and minified source code, simply use a tool like Fiddler or Wireshark and watch the traffic. You will find that it is very straightforward under the hood.
We use Web Audio for streaming via Aurora.js using a protocol very similar to HTTP Live Streaming. We did this because we wanted the same streaming backend to serve iPhone, Android and the web.
It was all a very long and painful process that took over 6 months of effort, but now that its all finished, its all good.
Have a look at http://radioflote.com and feel free to shoot questions or clarifications regarding anything. Go ahead and disassemble the code if you want to. Not a problem.
I have been looking for several days to find a way to do SHOUTcast Streaming in all major browsers without using a Flash Player, but I haven't been able to do so (except on Safari):
<audio controls src="http://38.96.175.97:7736/;"></audio>
The semicolon at the end of the "src" attribute forces the SHOUTcast server to ignore the user-agent string and use MPEG OVERRIDE instead, which does not contain Mozilla and is assumed to be an audio player. Sadly, this trick has only worked for me on Safari so far.
Does anyone have any idea of how to do this in other browsers (Chrome, Firefox, etc)?
The problem is not the issue with the User-Agent sniffing, but the fact that SHOUTcast servers do not send standard HTTP responses.
A normal HTTP response starts off with a status line that looks like this:
HTTP/1.0 200 OK
SHOUTcast servers send this instead:
ICY 200 OK
This works for many HTTP clients, but more and more HTTP clients break on a response like this.
The solution is to stop using SHOUTcast. Icecast is a good alternative. I have written my own called AudioPump Server to help with compatibility in browsers as well as Android clients.
If the stations you want to play aren't yours, you would have to proxy that playback through your own server to fix the status line problem.
You should try this tool.
http://www.schillmania.com/projects/soundmanager2/
It worked for me in any browser.
It also works on Android and iOS devices.
Ta-ta for now :)
I use JWPlayer to play videos from the server. Videos are encoded using h.264 codec. If i open them in browser with h.264 support - video plays nicely and i can seek it, because server returns 206 header browser understands that its partial content. But if i try to play same video on Opera, for example, flash player is being used and it receives 200 OK! 2 problems here:
I can't seek the video, until part of it is downloaded
If the video is not "properly" encoded player can't even start playing it, until file is fully downloaded.
Is there something wrong with flash properly asking/understanding http headers?(i've never worked with flash before, so maybe my question is a bit silly and i just don't know flash's limitations)..
1) You need to have pseudo streaming enabled, for Flash - http://www.longtailvideo.com/support/jw-player/28855/pseudo-streaming-in-flash, if you can provide a link though, I will take a look at exactly what is going on here, I am more or less guessing about this one. HTML5 does not require a pseudo streaming module to be installed on the server side, though. In Flash, the default is progressive download, so you can only seek to downloaded parts, and in html5, this is not the case.
2) Yes, that is because of encoding. If your MP4 files cannot be seeked before they are completely downloaded, you will have to fix the MOOV atom (it contains the seeking information) located at the end of your video. Use this little application to parse your videos and add the necessary cue points - http://renaun.com/blog/2010/06/qtindexswapper-2/
Also, encoding via HandBrake - http://handbrake.fr/, can fix this as well, so the above tool wouldn't be necessary. You can encode using HandBrake, and enable "web optimized", which does the same this as the Index Swapper Tool. HandBrake also has command line encoding options as well.
I would like to use mediaelement to play shoutcast internet radio stream.
The problem is that Firefox does not support html5 mp3. It would be nice to add failsafe flash player, or any other solution.
mediaelement.js has a built in flash player as a fallback. What issues are you having with it?
For our Shoutcast stream, we use "http://255.255.0.0/;stream.nsv" as the audio source (with a real IP address, of course). The semicolon is required and is what tells Shoutcast to deliver the stream instead of the admin page to the browser.