I am developing a WAP/mobile website that would allow users to stream audio/video (although the priority is audio) via their mobile browsers..
For music I would be streaming mp3 files, and for video I would be streaming flv and 3gp files (but mostly 3gp).
Can anyone recommend solutions (i.e. what to use and/or a point to the right direction) to enable streaming audio/video to a mobile browser?
AFAIK, there is RTSP (probably via Darwin Streaming Server?) which is supported in most 3G devices, and flash lite. (Would using flash lite as a player even be a good idea, since the users would need to have flash lite installed on their mobile devices? I'm not that familiar with flash.)
Most mobile phones support video streaming via RTSP, and the cheapest method is the Darwin Stream Server, and it integrates with the Real Video player
As for flash lite that has limited handset support so I wouldn't recommend using it.
The only thing I would add is that without wireless carrier support streaming of data to a mobile phone can be very expensive for an end user, so please ensure that the end user knows about the potential data charges
Related
I want to play RTSP stream from ip video cameras (MP4, H264) on my intranet web page, I use React. I have 12 cameras and NVR.
I did not find a way to do this without an intermediate server (Webrtc is not suitable), that spends resources on transcoding h264 stream to the mjpeg.
If I set a high resolution and quality of the stream, then a lot of resources are spent on transcoding, and most importantly, the streaming of mjpeg images takes a lot of traffic.
Is there a way or solution to stream from the ip camera directly to the web page so that the decoding is on the user's webbrowser side.
This will free the intermediate server from a heavy load for big streams.
It is necessary that the playback work on mobile phones.
Thanks for the answer.
There is no way to stream RTSP camera's H264 video directly to web browser.
But cameras support outputting still jpeg images - you can create a webpage that will display such an image from a camera every 200ms or so.
If you are not happy with the above solution, you must use a media server in between, which will pull RTSP stream from the camera and will convert it to some protocol that browser understands. You are mistaken in one thing: no video transcoding is involved. I don't know why WebRTC is not an option for you, but most media servers will offer 4 types of output:
Low latency:
WebRTC
Websockets to MSE
High latency:
HLS
MPEG-Dash
All these methods do NOT require transcoding of your original H264 video, encoded by RTSP camera/NVR. Some media servers you can use: Unreal Media Server, Wowza, Janus.
Live demo: http://www.umediaserver.net/umediaserver/demos.html
No browser has native RTSP support, so if you want decoding to happen on the end user side, then you'll have to write your own custom web player.
You can start by looking at the open-source solution like this one:
git://github.com/Streamedian/html5_rtsp_player.git
It works on PC and Android, but didn't work with iPhone for me (but you can try it for yourself https://streamedian.com/demonstration/ maybe it's just my issue), but maybe you can find better alternative or fork it and make it work on all devices.
It still requires a middle-man proxy server though because it uses a websocket tech to work, but since it doesn't do any video converting or decoding, it don't suppose to take any resources at all.
my current setup involves streaming from a GoPro to a linux box, and I managed to get bareSIP running on the box to stream the video locally with the 'v' command. However, there's no documentation or commands to configure an RTP broadcasting stream. Would anyone have any insight into publishing an RTP/RTSP output stream for other users to view on their devices?
I've used Unreal Streaming Media components and found them to be very good. They are lightweight and fast yet very powerful.
Using Unreal components you could install the stream forwarder on your laptop, point it at the RTSP stream and tell it to forward to the Distribution server application.
This app can host thousands of connections (supposedly) and last I looked you didn't need a license if you have 3 or fewer sources. The stream can be viewd via their own small player app, via a web player such as jPlayer or via VLC etc.
I've been pretty happy with this before - it saved me from having to use the Live555 streaming mess.
Good Luck!
I am trying to build a website and mobile app (iOS, Android) for the internet radio station.
Website users broadcast their music or radio and mobile users will just listen radio stations and chat with other listeners.
I searched a week and make a prototype with Wowza engine (using HLS and RTMP) and SHOUTcast server on Amazon EC2.
Using HLS has a delay with 5 seconds, but RTMP and SHOUTcast has 2 second delay.
With this result I think I should choose RTMP or SHOUTcast.
But I am not sure RTMP and SHOUTcast are the best protocol. :(
What protocol should I choose?
Do I need to provide a various protocol to cover all platform?
This is a very broad question. Let's start with the distribution protocol.
Streaming Protocol
HLS has the advantage of allowing users to get the stream in the bitrate that is best for their connection. Clients can scale up/down seamlessly without stopping playback. This is particularly important for video, but for audio even mobile clients are capable of playing 128kbit streams in most areas. If you intend to have a variety of bitrates available and want to change quality mid-stream, then HLS is a good protocol for you.
The downside of HLS is compatibility. iOS supports it, but that's about it. Android has HLS support but it is still buggy. (Maybe in another year or two once all the Android 3.0 folks are gone, this won't be as much of an issue.) JWPlayer has some hacks to make HLS work in Flash for desktop users.
I wouldn't bother with RTMP unless you're only concerned with Flash users.
Pure progressive streaming with HTTP is the route I almost always choose to go. Everything can play it. (Even my Palm Pilot's default media player from 12 years ago.) It's simple to implement and well understood.
SHOUTcast is effectively HTTP, but a poorly implemented version that has compatibility issues, particularly on mobile devices. It has a non-standard status line in its response which breaks a lot of clients. Icecast is a good alternative, and is what I would recommend for production use today. As another option, I have created my own streaming service called AudioPump which is HTTP as well, and has been specifically built to fix compatibility with oddball mobile clients, such as native Android players on old hardware. It isn't generally available yet, but you can contact me at brad#audiopump.co if you want to try it.
Latency
You mentioned a latency of 2 seconds being desirable. If you're getting 2-second latency with SHOUTcast, something is wrong. You don't want latency that low, particularly if you're streaming to mobile clients. I usually start with a 20-second buffer at a minimum, which is flushed to the client as fast as it can receive it. This enables immediate starting of the stream playback (as it fills up the client-side buffer so it can begin decoding) while providing some protection against buffer underruns due to network conditions. It's not uncommon for mobile users to walk around the corner of a building and lose their nice signal quality. You want your stream to survive that as best as possible, so if you have already sent the data to cover the drop out, the user doesn't have to know or care that their connection became mediocre for a short period of time.
If you do require low latency, you're looking at the wrong technology entirely. For low latency, check out WebRTC.
You certainly can tweak your traditional internet radio setup to reduce latency, but rarely is that a good idea.
Codec
Codec choice is what will dictate your compatibility more than anything else. MP3 is easily the most compatible, and AAC isn't far behind. If you go with AAC, you get better quality audio for a given bitrate. Most folks use this to reduce their bandwidth bill.
There are licensing fees with MP3, and there may be with AAC depending on what you're using for a codec. Check with a lawyer. I am not one, and the licensing is extremely complicated.
Other codecs include Vorbis and Opus. If you can use Opus, do so as the licensing is wide open and you get good quality for the bandwidth. Client compatibility here though is the killer of Opus. (Maybe in a few years it will be better.) Vorbis is a mediocre codec, but is free and clear.
On the extreme end, I have some stations doing their streaming in FLAC. This is lossless audio quality, but you're paying for 8x the bandwidth as you would with a medium quality MP3 station. FLAC over HTTP streaming compatibility is not code at the moment, but it works alright in VLC.
It is very common to support multiple codecs for your streams. Depending on your budget, if you can't do that, you're best off with MP3.
Finally on encoding, don't go from a lossy codec to another lossy codec if you can help it. Try to get the output stream as close to the input as possible. If you re-encode audio, you lose quality every time.
Recording from Browser
You mentioned users streaming from a browser. I built something like this a couple years ago with the Web Audio API where the audio is captured and then encoded and sent off to Icecast/SHOUTcast servers. Check it out here: http://demo.audiopump.co:3000/ A brief explanation of how it works is here: https://stackoverflow.com/a/20850467/362536
Anyway, I hope this helps you get started.
Streaming straight audio/mpeg (mp3 packets) has worked everywhere I've tried.
If you are developing an APP then go with AAC, if you are simply playing via web browser then you need a HTML5 Implimentation which is MP3. All custom protocols like RTMP or SHOUTcast requires additional UI to be built. There are some third party players available in open source world. You can either use them or stick to HTML5 MP3/OGG as most people now days are using chrome browser or other HTML5 complaint browsers.
I'm trying to put in place a basic streaming system from the browser.
The idea is to let the user stream audio live from his mic through the browser and then allow others to listen to this stream with their browser (desktop, mobile, etc ...) and iOS/Android apps.
I started doing some tests with the Red5 Server (which is a great free alternative to the Flash Media Server).
With this technologie, I can publish a stream with the RTMP (ex: rtmp://myserver/myApp).
But the problem is that I can't find a way to read the published stream on other plateforms (using the video tag with HTML5, in iOS, etc ...).
As i failed to that, my question is:
How can I let a user to stream his voice over the net (using flash or not) and then allow the others to listen to that stream by using lightweight technologies (HTML5) and mobile apps?
Thanks,
Regards
Looks like RED5 should be able to do what you want...
0.9.0 RC2 has the ability to:
Streaming Audio (MP3, F4A, M4A)
Recording Client Streams (FLV only)
some links that may help:
http://osflash.org/pipermail/red5_osflash.org/2007-April/010400.html
http://www.red5chat.com/
Though not exactly what you're after, you could take a look at BigBlueButton which is a web conferencing suite based on open source components (RED5 is one of them). It's has a rather complex architecture but they do have a flash based client you can take a loot at.
Songbird is an open source media player with lot of plugins. I want to broadcast media playing on my songbird over a network. Kindly, do not suggest me using another player.
Use pulseaudio as your audio framework - it has support for acting as a streaming server. It can play to both your local speakers and a network destination simultaneously.