I'm looking for somewhat for audio which is like Kewego or Dailymotion Cloud to video.
I'm looking for a good service to:
Encode user-uploaded audio files in predefined qualities
Stream it on demand in a more or less customisable player.
--
The goal is to run my own audio hosting platform, a bit like Soundcloud.
I'm open to all kinds of solutions, but I would prefer a cloud hosting with good API to interface it in a white label way. But if you know good server-side software, I could also use that...
Edit:
The bounty is now opened for 7 days and no answers: if you have any clues for me to achieve my platform, I'm interested...
API based encoder -> www.zencoder.com
Player -> If you are looking for something as robust as soundcloud, you are going to have to write that yourself. Otherwise something like jplayer could work. http://www.jplayer.org/latest/demos/
Home Baked -> A combination of FFMPEG + Wowza would give you a nice 1 - 2 punch for encoding / adaptive bitrate delivery. (Wowza doesn't support VOD transcoding with their "Transcode AddOn" yet, otherwise you would be able to use JUST wowza). They also have a deal with Amazon for daily instances if you just want to try it out.
Related
I'm trying to build a VOD service and not able to find a way to decide to which resolutions and bitrate a video should be transcoded after uploading. Like what if someone upload a shoot on a mobile phone.
I'm using AWS mediaconvert for transcoding.
There is no absolute rules here so you may find it easiest to simply look at some similar services to the one you want to offer and examine the resolutions/bit rates they are using.
Many services have ways to allow you look at what rates are available manually or even view how the stream changes over time - e.g.: https://stackoverflow.com/a/42365034/334402
It's worth thinking of your target devices also - if you are mostly targeting mobile phones (a service like Tik Tok for example) then you may not need the largest resolutions, while if you are targeting mainly large screens or VR devices high resolution may be very important for you.
Similarly the expected network connectivity will play a role - if most users will be at home and in a region with good connectivity then you may find less need for lower bit rate streams.
I have a Linode server and need to broadcast one to-many audio (they can hear but can not talk back) to a group of three to five people. I looked at WebRTC and the Janus server but it seems complete overkill. Using commercial applications like Skype, Discord etc. results in low audio quality and it is mono. Best possible audio quality and low latency (on a par with that of Skype, Discord etc.) is essential.
Any pointers would be greatly appreciated.
I can recommend building such system based on Icecast streaming. It's an old proven technology which has a latency close to real-time.
You could use any set of Icecast-enabled tools for that.
As example, here's what you an do with tools by our company:
Larix Broadcaster mobile app allows streaming in audio-only
mode.
Nimble Streamer software media server can get Larix' input and
produce Icecast stream. You can use any Icecast-enabled here
instead.
SLDP Player can play Icecast produced by Nimble
Streamer or any other Icecast-enabled server.
That can also be built with other companies products, so you can pick the right tools yourself.
A super simple setup would be to just use command line tool called ffmpeg (it also has an api) see doc at https://trac.ffmpeg.org/wiki/ffserver
Where your source audio lives just launch either the ffmpeg or ffserver
ffserver -f /etc/ffserver.conf
in that config put location of source audio and output url it will publish to ... then your client receivers can use ffplay with
ffplay <stream URL>
ffmpeg is a free open source industry workhorse for audio/video manipulation ... its the underlying technology several more visable tools like vlc use under the covers
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 working on a web app in node.js to allow clients to view a live streaming video via a unique url that another client will broadcast from their webcam, i.e., http://myapp.com/thevideo
I understand that webRTC is still not supported in enough browsers to be useful.
I would also like to save this the video stream to be viewed later within the app.
Things get somewhat confusing as I try to narrow down a solution to make this work.
I would like to get some recommendations on proven solutions out there to make this work on desktop and mobile? Any hints would be great.
I'll make a quick suggestion based on the limited details. I would use ffmpeg to encode to HLS. This format will playback natively on iOS and safari on Mac. For all other platforms, either provide an rtmp stream with a flash front end, or use jw player 6 commercial version that can play HLS. Or use a wowza server to handle this all for you.
.Hi everyone! I am looking forward to create a website with a live video streaming feature.
I have done some research and read about some applications including Flash Media Live Encoder.
Can anyone please guide me on how to start with this? Thanks!
It really depends from your requirements.
Do you need live streaming for big event or small event (what is your bandwidth)?
Do you need to stream to different devices (desktop+mobile)?
Do you have to stream your desktop/webcam or high quality camera feeds through capture cards?
Are you flexible with different Operative Systems?
Your question is too general. FMLE + FMS is a good solution, but FMS can be expensive.
Try to have a look also to Wowza.
If you just need a few live videos on your website, the solution is quite simple, Flash Media Live Encoder plus Flash Media Server are suitable.