Node-Media-Server | js implementation of RTMP/HTTP-FLV/WS-FLV/HLS/DASH/MP4 | Video Utils library

After some research, I got the solution.

The solution was painfully obvious

So node-media-server app listens for RTMP on port 1935. So the natural solution is to create and configure a firewall that will allow TCP connections through port 1935. For Ubuntu 18.0 Droplet the following does the trick.

First, find Your port with lsof -i :1935, then allow TCP connection over the port with sudo ufw allow 1935/tcp. Thus if the node-media-server is running, congrats! You can now use OBS like this rtmp://your_ip:1935/live/stream_key

Note that: Watch for the host Your app runs on. For me localhost worked, but with some Droplet configurations You might need to set it to 0.0.0.0

I found the problem, the first thing is to setup Nginx to listen on the port 80 only as node-media-server takes care of listening on the ports 8000 and 1935

You can add text to a video in a number of ways - most common are probably:

• Add a text track to the video container, i.e. the MP4 file. This is usually done server side and the client then uses this info to display it client side. You can see more info here and an example with a commonly used tool: https://www.bento4.com/developers/dash/subtitles/

• Embed the text in the frames themselves - this requires more processing and also adds the text to the video frames themselves, so you can't turn text on and off at the client easily. If you do want to do this then FFMPEG is probably a good place to start.

• Add a text overlay on the client itself - e.g. a text 'div' or element on a browser App, or a TextView on Android etc. You mention that synchronisation may be a problem, but you could take timing events from the video to trigger changing the text. This avoids you having to do any extra processing on the video or video container.

A simple example of using timing to trigger text is below - you would likely want to update it to avoid checking everything on each 'onTimeUpdate' event, and maybe to put the text over the video itself, but this give an example how the basic mechanism works:

You can't have two services listening on the same port.

The common solution is to configure the real service (your media service) on another port (let's say 19350) than configure a reverse proxy on nginix to forward requests from the exposed port (1935 in this case) to the back-end service (19350 in our example).

Sorry but I don't know nginix (I use this config with apache) so I can't help you on how to configure a reverse proxy on it.

This question is a bit broad, but I've built similar things and will try to answer this in pieces for you:

1. set the in-and-out times of the videos from the client, which requires the client to view the video at specific times, and switch the position of the video. Meaning, if a single video is used as an input, and split it into smaller parts, it needs to replay from the starting time of the next edited segment, if that makes sense.

Client-side, when you play back, you can simply use multiple HTMLVideoElement instances that reference the same URL.

For the timing, you can manage this yourself using the .currentTime property. However, you'll find that your JavaScript timing isn't going to be perfect. If you know your start/end points at the time of instantiation, you can use Media Fragment URIs:

HLS and MPEG DASH are not particularly low latency as standard and the figures you are getting are not unusual.

Some examples from a publicly available DASH forum document (linked below) include:

Given the resources of some of these organisations, the results you have achieved are not bad!

There is quite a focus in the streaming industry at this time on enabling lower latency, the target being to come as close as possible to traditional broadcast latency.

One key component of the latency in chunked Adaptive Bit Rate (ABR, see this answer for more info: https://stackoverflow.com/a/42365034/334402 ) is the need for the player to receive and decode one or more segments of the video before it can display it. Traditionally the player had to receive the entire segment before it could start to decode and display it. The diagram from the first linked open source reference below illustrates this:

Low latency DASH and HLS leverage CMAF, 'Common Media Application Format' which breaks the segments, which might be 6 seconds long for example, into smaller 'chunks' within each segment. These chunks are designed to allow the player to decode and start playing them before it has received the full segment.

Other sources of latency in a typical live stream will be any transcoding from one format to another and any delay in a streaming server receiving the feed, from the webcam in your case, and encoding and packaging it for streaming.

There is quite a lot of good information available on low latency streaming at this time both from standards bodies and open source discussions which I think will really help you appreciate the issues (all links current at time of writing). From open source and standards discussions:

• https://dashif.org/docs/Report%20on%20Low%20Latency%20DASH.pdf (DASH focus)
• https://github.com/video-dev/hlsjs-rfcs/pull/1. (HLS focus)

and from vendors:

• https://bitmovin.com/cmaf-low-latency-streaming/
• https://websites.fraunhofer.de/video-dev/dash-js-low-latency-streaming-with-cmaf/
• https://aws.amazon.com/blogs/media/alhls-apple-low-latency-http-live-streaming-explained/

Note - a common use case often quoted in the broadcast world is the case where someone watching a live event like a game may hear their neighbours celebrating a goal or touchdown before they see it themselves, because their feed has higher latency than their neighbours. While this is a driver for low latency, this is really a synchronisation issue which would require other solutions if a 'perfectly' synchronised solution was the goal.

As you can see low latency streaming is not a simple challenge and it may be that you want to consider other approaches depending on the details of your use case, including how many subscribers you have, whether some loss of quality if a fair trade off for lower latency etc. As mentioned by @user1390208 in the comments, a more real time focused video communication technology like WebRTC may be a better match for the solution you are targeting.

If you want to provide a service that provides life streaming and also a recording, you may want to consider using a real time protocol for the live streaming view and HLS/DASH streaming for anyone looking back through recordings where latency may not be important but quality may be more key.