I have a Linux PC which streams video (with audio) from a webcam to an RTMP server (nginx). The nginx RTMP server then converts the video into HLS and that HLS stream is shown on the browsers. Everything works good. The only problem is the delay due to the HLS protocol (10-20 seconds depending on the HLS playlist size).
I am looking for an alternative to HLS which can run on most of the major browsers. I can not use WebRTC due to the lack of audio, I can not use flash due to lack of support is mobile browsers. So my question is, is there any way to consume the RTMP stream, then distribute it via WebSocket and play on modern WebSocket supported browsers without any additional plugin? I am using ffmpeg to publish the RTMP stream from the Linux PC. If required, the source stream can easily be changed to other live streaming protocol like RTSP. So if there's some other solution which can solve this problem without RTMP, I can go for that too.
Thanks in advance.
Yes this is possible, but there's an even simpler solution. Just stream the data over HTTP.
WebSockets are only needed for bi-directional communication. You're just sending the video to the client.
Related
Currently I am trying to play the Hls stream that is being sent to my nginx server via rtmp, in Unity with this plugin: AVPro. It is working on my PC but I want to play it on Android and it seems like the codec is not supported for Android regardless of which Video API I use. Currently im sending the stream with Streamlabs if that is important.
So I wondered if it is possible to somehow change the codec that nginx is using for the Hls stream.
When I watch the stream on my PC with VLC Media Player and look at the codec information it tells me this:
Videocodec: H264 - MPEG-4 AVC(part 10) (h264)
Audiocodec: ADTS
Im using nginx for Windows and this version: nginx 1.7.11.3 Gryphon
And if it is not possible with nginx I would like to know if there is an alternative that you can use as a streaming server. I haven't really found anything yet.
I'm sending an RMTP stream named "testStream" to my AntMedia server. This stream can be viewed correctly on the page:
https://MYDOMAIN:5443/WebRTCAppEE/player.html
I would like to get the URL of the HLS stream to view the video within a native Android and iOS app. I've never done this before, I assume (indeed, I hope) that HLS is natively supported by both operating systems.
To get the HLS stream, I tried this URL:
https://MYDOMAIN:5443/WebRTCAppEE/streams/testStream.m3u8
It works, I tried that URL with VLC.
The only drawback is the delay, because the video stream has a ten-second delay. Opening the same video with a browser, at the address:
https://MYDOMAIN:5443/WebRTCAppEE/player.html
I don't notice any delay, and if there is, it's negligible.
Am I doing something wrong? I accept advice to embed the video into a native Android Studio and XCode app without delay, keeping the code as simple as possible. Thank you.
Thank you for your question,
https://MYDOMAIN:5443/WebRTCAppEE/player.html
plays stream with WebRTC so that there is no delay.
You can use https://MYDOMAIN:5443/WebRTCAppEE/play.html?id=testStream in your mobile to play with WebRTC.
Check the below doc for other options(WebRTC, HLS, etc.)
https://github.com/ant-media/Ant-Media-Server/wiki/Embedded-Web-Player
This is a process question more then anything.
I've been reading up on HTTP streaming (HLS) over the past week.
My goal is to be able to deliver content from my NGINX web server using HLS.
I have looked at Clappr using HLS.js. as a player however I'm just unclear what I need to do to deliver the content. Do I need a streaming media sever? just a web server?
I think I can use ffmpeg to make the HLS streams.
Eventually I'm hoping to be able to record incoming streams for processing later. Right now I just want to be able to put out HLS streams.
Any advice or infographic or something to put this in perspective would be appreciated.
Do I need a streaming media sever? just a web server?
One of the main purposes of HLS is that you can serve the data with any HTTP server. Content is effectively files done in chunks. No special streaming server is needed. Nginx is fine.
I was hoping to build an application that streams audio (mp3, ogg, etc.) from my microphone to a web browser.
I think I can use the html5 audio tag to read/play the stream from my server.
The area I'm really stuck on is how to setup the streaming http endpoint. What technologies will I need, and how should my server be structured to get the live audio from my mic and accessible from my server?
For example, for streaming mp3, do I constantly respond with mp3 frames as they are recorded?
Thanks for any help!
First off, let's split this problem up into a few parts. You have the audio capture (recording), the encoding/codec, the server, and the receiving clients.
Capture -> Codec -> Server -> Several Clients
For audio capture, you will need to use the Web Audio API along with getUserMedia. This will allow you to get 32-bit floating point PCM samples from the recording device. This data stream takes up a ton of bandwidth... a few megabit for a stereo stream. This stream is not directly playable in an HTML5 audio tag, and while you could play it on the receiving end with the Web Audio API, it takes up too much bandwidth to be useful. You need to use a codec to get the bandwidth usage down.
The codecs you want to look at include MP3, AAC (and its variants such as HE-AAC), and Opus. Not all browsers support all codecs. MP3 is the most widely compatible but AAC provides better quality for a given bitrate. Opus is a free and open codec but still doesn't have the greatest client adoption. In any case, there isn't yet a codec that you can run in-browser with any real stability. (Although it's being worked on! There are a lot of test projects made with Emscripten.) I solved this problem by reducing the bit depth of my samples to 16-bit signed integers and sending this PCM stream to a server to do the codec, over a binary websocket.
This encoding server took the PCM stream and ran it through a codec server-side. Here you can use whatever you'd like, such as a licensed codec binary or a tool like FFmpeg which encapsulates multiple codecs.
Next, this server streamed the data to a real streaming media server like Icecast. SHOUTcast and Icecast servers take the encoded stream and relay it to many clients over an HTTP-like connection. (Icecast is HTTP compliant whereas SHOUTcast is close but not quite there which can cause compatibility issues.)
Once you have your streaming server set up, it's as simple as referencing the stream URL in your <audio> tag.
Hopefully that gets you started. Depending on your needs, you might also look into WebRTC which does all of this for you but doesn't give you options for quality and also doesn't scale beyond a few users.
is http streaming possible without using any streaming servers?
Of course. You can output and flush, it gets to client before you end the script, thus it's streaming.
For live streaming, only segmented, like Apple HLS, other variants of segmented HLS (like OSMF) are not widely supported at the moment.
IIS from microsoft can also do smooth streaming (and Apple HLS as well).
Apple HLS can be supported on any web server when you pre-segment stream to chunks and just upload to web server path.
For VoD streaming, there is lot's of modules for all web servers.
Yes, although libraries have varying level of support. What needs to be used is "http chunking", such that lib does not try to buffer the whole request/response in memory (to computed the content length header) and instead indicate content comes in chunks.
Yes,not only its possible but has been implemented by various media server companies, only reason they still make usage of servers because of commercial purpose. Basically the content you want to stream should be divided into chunks/packets and then client machine can request those chunks via simple HTTP Get Requests.
Well if you have WebSockets available you can actually get quite low-latency streaming for low-fps scenarios by sending video frames as jpegs.
You can also send audio separately and play it using WebAudio on your browser. I imagine it could work for scenarios where you do not require perfect audio-video sync.
Another approach is to stream MPEG chunks through WebSockets, decode them in JS using jsmpeg and render to a canvas. You can find more here (video-only):
http://phoboslab.org/log/2013/09/html5-live-video-streaming-via-websockets
yes, the answer to your problem with http streaming is MPEG-DASH tech