NGINX RTMP Configurations

nginx.conf

worker_processes  auto;
events {
    # Allows up to 1024 connections, can be adjusted
    worker_connections  1024;
}

# RTMP configuration
rtmp {
    server {
        listen 1935; # Listen on standard RTMP port
        chunk_size 4000; 

        # This application is to accept incoming stream
        application live {
            live on; # Allows live input

            # Once receive stream, transcode for adaptive streaming
            # This single ffmpeg command takes the input and transforms
            # the source into 4 different streams with different bitrate
            # and quality. P.S. The scaling done here respects the aspect
            # ratio of the input.
            exec ffmpeg -i rtmp://192.168.1.68/live/$name -async 1 -vsync -1 
            -c:v libx264 -c:a libfdk_aac -b:v 256k -b:a 32k -vf "scale=480:trunc(ow/a/2)*2" -tune zerolatency -preset veryfast -crf 23 -f flv rtmp://192.168.1.68/show/$name_low
            -c:v libx264 -c:a libfdk_aac -b:v 768k -b:a 96k -vf "scale=720:trunc(ow/a/2)*2" -tune zerolatency -preset veryfast -crf 23 -f flv rtmp://192.168.1.68/show/$name_mid
            # -c:v libx264 -c:a libfdk_aac -b:v 1024k -b:a 128k -vf "scale=960:trunc(ow/a/2)*2" -tune zerolatency -preset veryfast -crf 23 -f flv rtmp://192.168.1.68/show/$name_high
            -c:v libx264 -c:a libfdk_aac -b:v 1920k -b:a 128k -vf "scale=1280:trunc(ow/a/2)*2" -tune zerolatency -preset veryfast -crf 23 -f flv rtmp://192.168.1.68/show/$name_hd720
            -c copy -f flv rtmp://192.168.1.68/show/stream;
        }
        
        # This application is for splitting the stream into HLS fragments
        application show {
            live 		on; 	# Allows live input from above
            hls 		on; 	# Enable HTTP Live Streaming
	        # hls_fragment	5s;

            # Pointing this to an SSD is better as this involves lots of IO
            hls_path /tmp/hls/;
            
            # Instruct clients to adjust resolution according to bandwidth
            hls_variant _low BANDWIDTH=288000; # Low bitrate, sub-SD resolution
            hls_variant _mid BANDWIDTH=448000; # Medium bitrate, SD resolution
            # hls_variant _high BANDWIDTH=1152000; # High bitrate, higher-than-SD resolution
            hls_variant _hd720 BANDWIDTH=2048000; # High bitrate, HD 720p resolution
            # hls_variant _src BANDWIDTH=4096000; # Source bitrate, source resolution
        }
    }
}

http {
    # See http://licson.net/post/optimizing-nginx-for-large-file-delivery/ for more detail
    # This optimizes the server for HLS fragment delivery
    sendfile off;
    tcp_nopush on;
    directio 512;
    
    # HTTP server required to serve the player and HLS fragments
    server {
        listen 80;
        error_log /home/user/build/logs/rtmp.log debug;
        error_log /home/user/build/logs/rtmp-error.log;
        # error_log /home/user/build/logs/rtmp-info.log info;
        # error_log /home/user/build/logs/rtmp-notice.log notice;

        
        location / {
            root html;
        }
        
        location /hls {
            types {
                application/vnd.apple.mpegurl m3u8;
            }
            
            root /tmp/;
            add_header Cache-Control no-cache; # Prevent caching of HLS fragments
            add_header Access-Control-Allow-Origin *; # Allow web player to access our playlist
        }
    }
}

@ashadnasim52 it will automatically adjust the stream resolution/bitrate on the basis of internet speed.

As in the line below:
hls_variant _low BANDWIDTH=288000; # Low bitrate, sub-SD resolution

That IP address on the ffmpeg command is the local IP address for the Server, right?

If it is of any use, writing some ancient memory, the RTMP protocol supports adaptive bandwidth for a single stream. RTMP It is full duplex and accepts extra data channels.

Usually, during streaming:

• The RTMP client can call bwcheck on the server
• The server receives onBWCheck event
• The server then respond by invoking bwdone on the client, client receives onBWDone

Measuring the round-trip time from time to time, plus some probing payloads of defined sizes than can be sent to the server, can be used to then adapt bitrate, framerate, audiorate, frame drop and even resolution.

Although this is a technique that was used in the now dead Flash, the wide usage and simplicity of the RTMP protocol compared to WebRTC, still makes it unbeatable. The endpoint can output HLS (that browsers can naively play with libraries like hls.js)

Here are some resources

• https://www.wowza.com/community/t/dynamic-bandwidth-detection-bwcheck/73
• https://codebelt.github.io/blog/actionscript-3/as3-onbwdone-error-flash-media-server-with-amazon-cloudfront/
• https://www.wowza.com/docs/how-to-test-server-to-client-bandwidth-for-rtmp-clients
• https://www.cnblogs.com/jimodetiantang/p/9081876.html

If the thing you are streaming from is bandwidth constrained, this can be a good start.
Check the sources of ffmpeg rtmp client, there you will find onBWCheck

That IP address on the ffmpeg command is the local IP address for the Server, right?

It should be the IP of your RTMP steam it could be local or some external server.

Hi, I tried this configuration with input rtmp stream with keys. So without this conf I have index.m3u8 containings keys and ts files. When I run with your conf I have generated other streams only for few first ts so I assume that I have to have input directly index.m3u8. Does anybody tried this situation? Thank you

This is not work for me. I need record and send to s3, but I got I/O error on folder that should record/send to s3.

Can you provide links for an OBS input video output receiving?

I would love to see an example with an HTML video player to play the output