Top Related Projects
A Node.js implementation of RTMP/HTTP-FLV/WS-FLV/HLS/DASH/MP4 Media Server
SRS is a simple, high-efficiency, real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181.
🐋 A Dockerfile for nginx-rtmp-module + FFmpeg from source with basic settings for streaming HLS. Built on Alpine Linux.
A media streaming server based on nginx-rtmp-module. In addtion to the features nginx-rtmp-module provides, HTTP-FLV, GOP cache, VHosts (one IP for multi domain names) and JSON style statistics are supported now.
Quick Overview
The nginx-rtmp-module is an open-source NGINX module that adds RTMP, HLS, and DASH streaming capabilities to the NGINX web server. It enables live streaming and video-on-demand functionality, making it a popular choice for building streaming servers and applications.
Pros
- Easy integration with existing NGINX setups
- Supports multiple streaming protocols (RTMP, HLS, DASH)
- Highly performant and scalable
- Active community and ongoing development
Cons
- Requires compilation from source, which may be challenging for some users
- Limited documentation compared to commercial streaming solutions
- May require additional configuration for advanced use cases
- Lacks some features found in dedicated streaming servers
Code Examples
- Basic RTMP server configuration:
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on;
record off;
}
}
}
This example sets up a basic RTMP server listening on port 1935 with live streaming enabled.
- HLS streaming configuration:
rtmp {
server {
listen 1935;
chunk_size 4096;
application hls {
live on;
hls on;
hls_path /tmp/hls;
hls_fragment 3s;
hls_playlist_length 60s;
}
}
}
This configuration enables HLS streaming, storing fragments in the /tmp/hls
directory with 3-second fragments and a 60-second playlist length.
- DASH streaming configuration:
rtmp {
server {
listen 1935;
chunk_size 4096;
application dash {
live on;
dash on;
dash_path /tmp/dash;
dash_fragment 5s;
}
}
}
This example sets up DASH streaming with fragments stored in the /tmp/dash
directory and a 5-second fragment duration.
Getting Started
-
Clone the repository:
git clone https://github.com/arut/nginx-rtmp-module.git
-
Download and extract the NGINX source code:
wget https://nginx.org/download/nginx-1.21.6.tar.gz tar -xzf nginx-1.21.6.tar.gz
-
Compile NGINX with the RTMP module:
cd nginx-1.21.6 ./configure --add-module=../nginx-rtmp-module make sudo make install
-
Configure NGINX with RTMP settings (see code examples above).
-
Start NGINX:
sudo nginx
Your NGINX RTMP server is now ready to use.
Competitor Comparisons
A Node.js implementation of RTMP/HTTP-FLV/WS-FLV/HLS/DASH/MP4 Media Server
Pros of Node-Media-Server
- Written in JavaScript, making it easier for web developers to understand and modify
- Supports multiple streaming protocols (RTMP, HTTP-FLV, WebSocket-FLV, HLS, DASH)
- Includes built-in authentication and authorization features
Cons of Node-Media-Server
- May have lower performance compared to nginx-rtmp-module, especially for high-traffic scenarios
- Less mature and battle-tested in production environments
- Smaller community and ecosystem compared to nginx-based solutions
Code Comparison
nginx-rtmp-module (C):
ngx_rtmp_stat_loc_conf_t *slcf = conf;
ngx_http_core_loc_conf_t *clcf;
clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module);
clcf->handler = ngx_rtmp_stat_handler;
Node-Media-Server (JavaScript):
const NodeMediaServer = require('node-media-server');
const config = {
rtmp: { port: 1935, chunk_size: 60000, gop_cache: true, ping: 30, ping_timeout: 60 },
http: { port: 8000, allow_origin: '*' }
};
var nms = new NodeMediaServer(config);
nms.run();
The code snippets demonstrate the configuration and setup process for each project. nginx-rtmp-module uses C and integrates with the nginx web server, while Node-Media-Server uses JavaScript and can be easily set up as a standalone application.
SRS is a simple, high-efficiency, real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181.
Pros of SRS
- More comprehensive feature set, including support for multiple protocols (RTMP, HLS, WebRTC, etc.)
- Better performance and scalability, capable of handling higher concurrent connections
- Active development and community support, with frequent updates and improvements
Cons of SRS
- Steeper learning curve due to more complex configuration options
- Larger codebase and resource footprint compared to nginx-rtmp-module
Code Comparison
nginx-rtmp-module:
rtmp {
server {
listen 1935;
application live {
live on;
}
}
}
SRS:
listen 1935;
max_connections 1000;
vhost __defaultVhost__ {
hls {
enabled on;
hls_path ./objs/nginx/html;
hls_fragment 10;
hls_window 60;
}
}
The nginx-rtmp-module configuration is simpler and more straightforward, while SRS offers more detailed options for fine-tuning the streaming server's behavior.
SRS provides a more feature-rich and scalable solution for live streaming, but it comes with increased complexity. nginx-rtmp-module, on the other hand, offers a simpler setup and integration with the widely-used Nginx web server. The choice between the two depends on specific project requirements, desired features, and the level of customization needed.
🐋 A Dockerfile for nginx-rtmp-module + FFmpeg from source with basic settings for streaming HLS. Built on Alpine Linux.
Pros of docker-nginx-rtmp
- Containerized solution, easier to deploy and manage
- Includes pre-configured environment with NGINX and RTMP module
- Simplified setup process for streaming applications
Cons of docker-nginx-rtmp
- Less flexibility for custom configurations
- Potential performance overhead due to containerization
- May require additional steps for integration with existing systems
Code Comparison
nginx-rtmp-module:
rtmp {
server {
listen 1935;
application live {
live on;
record off;
}
}
}
docker-nginx-rtmp:
FROM tiangolo/nginx-rtmp
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 1935
EXPOSE 8080
CMD ["nginx", "-g", "daemon off;"]
The nginx-rtmp-module provides a more direct configuration approach, allowing users to define RTMP settings within the NGINX configuration file. In contrast, docker-nginx-rtmp encapsulates the NGINX and RTMP module setup within a Docker container, simplifying deployment but potentially limiting fine-grained control.
Both projects aim to facilitate RTMP streaming with NGINX, but they cater to different use cases and deployment preferences. nginx-rtmp-module offers more flexibility for advanced users, while docker-nginx-rtmp provides a more streamlined solution for those preferring containerized deployments.
A media streaming server based on nginx-rtmp-module. In addtion to the features nginx-rtmp-module provides, HTTP-FLV, GOP cache, VHosts (one IP for multi domain names) and JSON style statistics are supported now.
Pros of nginx-http-flv-module
- Supports HTTP-FLV streaming, which can be more compatible with various devices and browsers
- Includes additional features like GOP cache and stream relay
- More actively maintained with recent updates and improvements
Cons of nginx-http-flv-module
- May have a steeper learning curve due to additional features and configuration options
- Potentially higher resource usage compared to the simpler nginx-rtmp-module
Code Comparison
nginx-rtmp-module configuration:
rtmp {
server {
listen 1935;
application live {
live on;
}
}
}
nginx-http-flv-module configuration:
http {
server {
listen 8080;
location /live {
flv_live on;
chunked_transfer_encoding on;
}
}
}
rtmp {
server {
listen 1935;
application live {
live on;
http_flv on;
}
}
}
The nginx-http-flv-module configuration includes both RTMP and HTTP-FLV settings, providing more flexibility but requiring additional setup. The nginx-rtmp-module configuration is simpler but limited to RTMP streaming only.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
NGINX-based Media Streaming Server
nginx-rtmp-module
Project blog
http://nginx-rtmp.blogspot.com
Wiki manual
https://github.com/arut/nginx-rtmp-module/wiki/Directives
Google group
https://groups.google.com/group/nginx-rtmp
https://groups.google.com/group/nginx-rtmp-ru (Russian)
Donation page (Paypal etc)
http://arut.github.com/nginx-rtmp-module/
Features
-
RTMP/HLS/MPEG-DASH live streaming
-
RTMP Video on demand FLV/MP4, playing from local filesystem or HTTP
-
Stream relay support for distributed streaming: push & pull models
-
Recording streams in multiple FLVs
-
H264/AAC support
-
Online transcoding with FFmpeg
-
HTTP callbacks (publish/play/record/update etc)
-
Running external programs on certain events (exec)
-
HTTP control module for recording audio/video and dropping clients
-
Advanced buffering techniques to keep memory allocations at a minimum level for faster streaming and low memory footprint
-
Proved to work with Wirecast, FMS, Wowza, JWPlayer, FlowPlayer, StrobeMediaPlayback, ffmpeg, avconv, rtmpdump, flvstreamer and many more
-
Statistics in XML/XSL in machine- & human- readable form
-
Linux/FreeBSD/MacOS/Windows
Build
cd to NGINX source directory & run this:
./configure --add-module=/path/to/nginx-rtmp-module
make
make install
Several versions of nginx (1.3.14 - 1.5.0) require http_ssl_module to be added as well:
./configure --add-module=/path/to/nginx-rtmp-module --with-http_ssl_module
For building debug version of nginx add --with-debug
./configure --add-module=/path/to-nginx/rtmp-module --with-debug
Windows limitations
Windows support is limited. These features are not supported
- execs
- static pulls
- auto_push
RTMP URL format
rtmp://rtmp.example.com/app[/name]
app - should match one of application {} blocks in config
name - interpreted by each application can be empty
Multi-worker live streaming
Module supports multi-worker live streaming through automatic stream pushing to nginx workers. This option is toggled with rtmp_auto_push directive.
Example nginx.conf
rtmp {
server {
listen 1935;
chunk_size 4000;
# TV mode: one publisher, many subscribers
application mytv {
# enable live streaming
live on;
# record first 1K of stream
record all;
record_path /tmp/av;
record_max_size 1K;
# append current timestamp to each flv
record_unique on;
# publish only from localhost
allow publish 127.0.0.1;
deny publish all;
#allow play all;
}
# Transcoding (ffmpeg needed)
application big {
live on;
# On every pusblished stream run this command (ffmpeg)
# with substitutions: $app/${app}, $name/${name} for application & stream name.
#
# This ffmpeg call receives stream from this application &
# reduces the resolution down to 32x32. The stream is the published to
# 'small' application (see below) under the same name.
#
# ffmpeg can do anything with the stream like video/audio
# transcoding, resizing, altering container/codec params etc
#
# Multiple exec lines can be specified.
exec ffmpeg -re -i rtmp://localhost:1935/$app/$name -vcodec flv -acodec copy -s 32x32
-f flv rtmp://localhost:1935/small/${name};
}
application small {
live on;
# Video with reduced resolution comes here from ffmpeg
}
application webcam {
live on;
# Stream from local webcam
exec_static ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an
-f flv rtmp://localhost:1935/webcam/mystream;
}
application mypush {
live on;
# Every stream published here
# is automatically pushed to
# these two machines
push rtmp1.example.com;
push rtmp2.example.com:1934;
}
application mypull {
live on;
# Pull all streams from remote machine
# and play locally
pull rtmp://rtmp3.example.com pageUrl=www.example.com/index.html;
}
application mystaticpull {
live on;
# Static pull is started at nginx start
pull rtmp://rtmp4.example.com pageUrl=www.example.com/index.html name=mystream static;
}
# video on demand
application vod {
play /var/flvs;
}
application vod2 {
play /var/mp4s;
}
# Many publishers, many subscribers
# no checks, no recording
application videochat {
live on;
# The following notifications receive all
# the session variables as well as
# particular call arguments in HTTP POST
# request
# Make HTTP request & use HTTP retcode
# to decide whether to allow publishing
# from this connection or not
on_publish http://localhost:8080/publish;
# Same with playing
on_play http://localhost:8080/play;
# Publish/play end (repeats on disconnect)
on_done http://localhost:8080/done;
# All above mentioned notifications receive
# standard connect() arguments as well as
# play/publish ones. If any arguments are sent
# with GET-style syntax to play & publish
# these are also included.
# Example URL:
# rtmp://localhost/myapp/mystream?a=b&c=d
# record 10 video keyframes (no audio) every 2 minutes
record keyframes;
record_path /tmp/vc;
record_max_frames 10;
record_interval 2m;
# Async notify about an flv recorded
on_record_done http://localhost:8080/record_done;
}
# HLS
# For HLS to work please create a directory in tmpfs (/tmp/hls here)
# for the fragments. The directory contents is served via HTTP (see
# http{} section in config)
#
# Incoming stream must be in H264/AAC. For iPhones use baseline H264
# profile (see ffmpeg example).
# This example creates RTMP stream from movie ready for HLS:
#
# ffmpeg -loglevel verbose -re -i movie.avi -vcodec libx264
# -vprofile baseline -acodec libmp3lame -ar 44100 -ac 1
# -f flv rtmp://localhost:1935/hls/movie
#
# If you need to transcode live stream use 'exec' feature.
#
application hls {
live on;
hls on;
hls_path /tmp/hls;
}
# MPEG-DASH is similar to HLS
application dash {
live on;
dash on;
dash_path /tmp/dash;
}
}
}
# HTTP can be used for accessing RTMP stats
http {
server {
listen 8080;
# This URL provides RTMP statistics in XML
location /stat {
rtmp_stat all;
# Use this stylesheet to view XML as web page
# in browser
rtmp_stat_stylesheet stat.xsl;
}
location /stat.xsl {
# XML stylesheet to view RTMP stats.
# Copy stat.xsl wherever you want
# and put the full directory path here
root /path/to/stat.xsl/;
}
location /hls {
# Serve HLS fragments
types {
application/vnd.apple.mpegurl m3u8;
video/mp2t ts;
}
root /tmp;
add_header Cache-Control no-cache;
}
location /dash {
# Serve DASH fragments
root /tmp;
add_header Cache-Control no-cache;
}
}
}
Multi-worker streaming example
rtmp_auto_push on;
rtmp {
server {
listen 1935;
application mytv {
live on;
}
}
}
Top Related Projects
A Node.js implementation of RTMP/HTTP-FLV/WS-FLV/HLS/DASH/MP4 Media Server
SRS is a simple, high-efficiency, real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181.
🐋 A Dockerfile for nginx-rtmp-module + FFmpeg from source with basic settings for streaming HLS. Built on Alpine Linux.
A media streaming server based on nginx-rtmp-module. In addtion to the features nginx-rtmp-module provides, HTTP-FLV, GOP cache, VHosts (one IP for multi domain names) and JSON style statistics are supported now.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot