Convert Figma logo to code with AI

winshining logonginx-http-flv-module

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.

2,731
569
2,731
24

Top Related Projects

NGINX-based Media Streaming Server

A Node.js implementation of RTMP/HTTP-FLV/WS-FLV/HLS/DASH/MP4 Media Server

25,534

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.

NGINX-based MP4 Repackager

Quick Overview

The nginx-http-flv-module is an NGINX module that provides support for the HTTP-FLV (Flash Video) live streaming protocol. It allows NGINX to serve live video streams in the FLV format, which is commonly used for web-based video players.

Pros

  • Real-time Streaming: The module enables real-time video streaming, making it suitable for live events, video conferencing, and other applications that require low-latency video delivery.
  • Compatibility: The module is compatible with a wide range of video players and clients that support the HTTP-FLV protocol, including popular web-based video players.
  • Scalability: NGINX is known for its high-performance and scalable architecture, which can benefit the nginx-http-flv-module in terms of handling large numbers of concurrent connections.
  • Customization: The module provides various configuration options, allowing developers to tailor the streaming behavior to their specific needs.

Cons

  • Limited Adoption: The module is not part of the core NGINX distribution, so it may not be as widely adopted or supported as some other NGINX modules.
  • Dependency on NGINX: The module is tightly coupled with NGINX, meaning that users must have NGINX installed and configured to use the module.
  • Potential Complexity: Integrating the module into an existing NGINX setup may require some technical expertise, especially for users who are not familiar with NGINX configuration.
  • Lack of Official Documentation: The project's documentation may not be as comprehensive as some users would prefer, which could make it more challenging to get started with the module.

Code Examples

N/A (This is not a code library)

Getting Started

N/A (This is not a code library)

Competitor Comparisons

NGINX-based Media Streaming Server

Pros of nginx-rtmp-module

  • More established and widely used in production environments
  • Supports a broader range of RTMP features and functionalities
  • Better documentation and community support

Cons of nginx-rtmp-module

  • Limited to RTMP protocol, lacking support for HTTP-based streaming
  • Less active development and fewer recent updates
  • May require additional modules or configurations for modern streaming setups

Code Comparison

nginx-rtmp-module:

rtmp {
    server {
        listen 1935;
        application live {
            live on;
            record off;
        }
    }
}

nginx-http-flv-module:

http {
    server {
        listen 8080;
        location /live {
            flv_live on;
            chunked_transfer_encoding on;
        }
    }
}

The nginx-rtmp-module uses the RTMP protocol and requires a separate RTMP server block, while nginx-http-flv-module integrates with the HTTP server configuration and uses the FLV format over HTTP.

nginx-http-flv-module offers a more modern approach with HTTP-based streaming, which can be advantageous for compatibility with various devices and firewalls. It also provides additional features like WebSocket support and DASH streaming.

However, nginx-rtmp-module remains a solid choice for traditional RTMP streaming setups and has a longer track record in production environments.

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 a built-in authentication system and API for stream management

Cons of Node-Media-Server

  • May have lower performance compared to nginx-based solutions for high-traffic scenarios
  • Lacks some advanced features found in nginx modules, such as transcoding or adaptive bitrate streaming

Code Comparison

Node-Media-Server:

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();

nginx-http-flv-module:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            http_flv on;
        }
    }
}

Both projects aim to provide HTTP-FLV streaming capabilities, but they differ in implementation and features. Node-Media-Server offers a more accessible JavaScript-based solution with built-in multi-protocol support, while nginx-http-flv-module provides a high-performance C-based module for the nginx web server, potentially offering better scalability for large-scale deployments.

25,534

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 streaming solution with support for multiple protocols (RTMP, HLS, WebRTC, etc.)
  • Built-in web-based management console for easier configuration and monitoring
  • Active development with frequent updates and a larger community

Cons of SRS

  • Higher resource consumption due to its full-featured nature
  • Steeper learning curve for basic setups compared to nginx-http-flv-module

Code Comparison

SRS configuration example:

listen              1935;
max_connections     1000;
srs_log_tank        file;
srs_log_file        ./objs/srs.log;
http_server {
    enabled         on;
    listen          8080;
}

nginx-http-flv-module configuration example:

rtmp {
    server {
        listen 1935;
        application live {
            live on;
            http_flv on;
        }
    }
}

Summary

SRS offers a more feature-rich streaming solution with support for multiple protocols and a built-in management console. However, it may consume more resources and have a steeper learning curve. nginx-http-flv-module is simpler and more lightweight but focuses primarily on HTTP-FLV streaming. The choice between the two depends on specific project requirements and the desired level of functionality.

🐋 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 RTMP module out-of-the-box
  • Simpler setup for basic streaming needs

Cons of docker-nginx-rtmp

  • Limited to RTMP protocol, less flexible for modern streaming requirements
  • Fewer customization options compared to nginx-http-flv-module
  • Less active development and community support

Code Comparison

nginx-http-flv-module configuration:

http {
    server {
        listen 8080;
        location /live {
            flv_live on;
        }
    }
}

docker-nginx-rtmp configuration:

rtmp {
    server {
        listen 1935;
        application live {
            live on;
        }
    }
}

The nginx-http-flv-module provides HTTP-FLV streaming, which can be more compatible with modern web browsers. It offers more advanced features and customization options, making it suitable for complex streaming setups.

On the other hand, docker-nginx-rtmp offers a simpler, containerized solution that's easier to deploy for basic RTMP streaming needs. However, it may be less flexible for advanced use cases and modern streaming protocols.

Both projects serve different needs, with nginx-http-flv-module being more feature-rich and customizable, while docker-nginx-rtmp provides a quick and easy solution for RTMP streaming in a containerized environment.

NGINX-based MP4 Repackager

Pros of nginx-vod-module

  • Supports a wider range of video formats, including MP4, DASH, HLS, and more
  • Offers advanced features like dynamic packaging and on-the-fly transcoding
  • Provides better integration with content delivery networks (CDNs)

Cons of nginx-vod-module

  • More complex setup and configuration compared to nginx-http-flv-module
  • Potentially higher resource usage due to advanced features
  • May have a steeper learning curve for beginners

Code Comparison

nginx-vod-module configuration example:

location /vod/ {
    vod;
    vod_mode local;
    vod_fallback_upstream fallback;
    alias /path/to/video/files/;
}

nginx-http-flv-module configuration example:

location /flv {
    flv_live on;
    chunked_transfer_encoding on;
    add_header 'Access-Control-Allow-Origin' '*';
    add_header 'Access-Control-Allow-Credentials' 'true';
}

The nginx-vod-module configuration demonstrates its flexibility in handling various video formats and delivery methods, while the nginx-http-flv-module configuration focuses specifically on FLV live streaming with simpler setup.

Both modules extend Nginx's capabilities for video streaming, but nginx-vod-module offers more advanced features at the cost of increased complexity, while nginx-http-flv-module provides a more straightforward solution for FLV streaming.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

nginx-http-flv-module

nginx-http-flv-module workflow

A media streaming server based on nginx-rtmp-module.

中文说明.

Donate if you like this module. Many thanks to you!

PayPal

Credits

Features

Featuresnginx-http-flv-modulenginx-rtmp-moduleRemarks
HTTP-FLV (for play)√xHTTPS-FLV and chunked response supported
GOP cache√x
Virtual Host√x
Omit listen directive√See remarksThere MUST be at least one listen directive
Audio-only support for RTMP/HTTP-FLV√See remarksWon't work if wait_video or wait_key is on
Single-track support for HLS√x
reuseport support√x
Timer for access log√x
JSON style statistics√x
Statistics for recordings√x
Independent of endianness√See remarksPartially supported in branch big-endian

Compatibility

The NGINX version SHOULD be equal to or greater than 1.2.6, the compatibility with other versions is unknown.

Systems supported

  • Linux (recommended) / FreeBSD / MacOS / Windows (limited).

Players supported

Note

Prerequisites

  • GNU make for activating compiler on Unix-like systems to compile software.

  • GCC for compilation on Unix-like systems or MSVC for compilation on Windows.

  • GDB for debug on Unix-like systems.

  • FFmpeg or OBS for publishing media streams.

  • VLC (recommended) or flv.js (recommended) for playing media streams.

  • PCRE for NGINX if regular expressions needed.

  • OpenSSL for NGINX if encrypted access needed.

  • zlib for NGINX if compression needed.

Build

Note

nginx-http-flv-module has all features that nginx-rtmp-module provides, so DON'T compile nginx-http-flv-module along with nginx-rtmp-module.

On Windows

For details about build steps, please refer to Building nginx on the Win32 platform with Visual C, and don't forget to add --add-module=/path/to/nginx-http-flv-module in Run configure script step.

Note

If some compilers which do not support x64 perfectly, VS2010 for example, are used to compile the module, please make sure that the default settings are used (target machine type x86).

On Unix-like systems

Download NGINX and nginx-http-flv-module.

Uncompress them.

cd to NGINX source directory & run this:

Compile the module into NGINX

./configure --add-module=/path/to/nginx-http-flv-module
make
make install

or

Compile the module as a dynamic module

./configure --add-dynamic-module=/path/to/nginx-http-flv-module
make
make install

Note

If the module is compiled as a dynamic module, the NGINX version MUST be equal to or greater than 1.9.11.

Usage

For details of usages of nginx-rtmp-module, please refer to README.md.

Publish

For simplicity, transcoding is not used (so -c copy is used):

ffmpeg -re -i MEDIA_FILE_NAME -c copy -f flv rtmp://example.com[:port]/appname/streamname

Note

Some legacy versions of FFmpeg don't support the option -c copy, the options -vcodec copy -acodec copy can be used instead.

The appname is used to match an application block in rtmp block (see below for details).

The streamname can be specified at will but can NOT be omitted.

The default port for RTMP is 1935, if some other ports were used, :port must be specified.

Play

via HTTP-FLV

http://example.com[:port]/dir?[port=xxx&]app=appname&stream=streamname

Note

  • If ffplay is used in command line to play the stream, the url above MUST be enclosed by quotation marks, or arguments in url will be discarded (some shells not so smart will interpret "&" as "run in background").

  • If flv.js is used to play the stream, make sure that the published stream is encoded properly, for flv.js supports ONLY H.264 encoded video and AAC/MP3 encoded audio.

The dir is used to match location blocks in http block (see below for details).

The default port for HTTP is 80, if some other ports were used, :port must be specified.

The default port for RTMP is 1935, if some other ports were used, port=xxx must be specified.

The value of app (appname) is used to match an application block, but if the requested app appears in several server blocks and those blocks have the same address and port configuration, host name matches server_name directive will be additionally used to identify the requested application block, otherwise the first one is matched.

The value of stream (streamname) is used to match the name of published stream.

Example

Assume that listen directive specified in http block is:

http {
    ...
    server {
        listen 8080; #not default port 80
        ...

        location /live {
            flv_live on;
        }
    }
}

And listen directive specified in rtmp block is:

rtmp {
    ...
    server {
        listen 1985; #not default port 1935
        ...

        application myapp {
            live on;
        }
    }
}

And the name of published stream is mystream, then the url of playback based on HTTP is:

http://example.com:8080/live?port=1985&app=myapp&stream=mystream

Note

Since some players don't support HTTP chunked transmission, it's better to specify chunked_transfer_encoding off; in location where flv_live on; is specified in this case, or play will fail.

via RTMP

rtmp://example.com[:port]/appname/streamname

via HLS

http://example.com[:port]/dir/streamname.m3u8

via DASH

http://example.com[:port]/dir/streamname.mpd

Sample Pictures

RTMP (JW Player) & HTTP-FLV (VLC)

RTMP & HTTP-FLV

HTTP-FLV (flv.js)

HTTP-FLV

Example nginx.conf

Note

The directives rtmp_auto_push, rtmp_auto_push_reconnect and rtmp_socket_dir will not function on Windows except on Windows 10 17063 and later versions, because relay in multiple processes mode needs help of Unix domain socket, please refer to Unix domain socket on Windows 10 for details.

It's better to specify the directive worker_processes as 1, because ngx_rtmp_stat_module may not get statistics from a specified worker process in multi-processes mode, for HTTP requests are randomly distributed to worker processes. ngx_rtmp_control_module has the same problem. The problem can be optimized by this patch per-worker-listener.

In addtion, vhost feature is OK in single process mode but not perfect in multi-processes mode yet, waiting to be fixed. For example, the following configuration is OK in multi-processes mode:

rtmp {
    ...
    server {
        listen 1935;
        server_name domain_name;

        application myapp {
            ...
        }
    }
}

While the following configuration doesn't work properly for play requests distinated to the second server (whether port is 1935 or not) of non-publisher worker processes:

rtmp {
    ...
    server {
        listen 1935;
        server_name 1st_domain_name;

        application myapp {
            ...
        }
    }

    server {
        listen 1945;
        server_name 2nd_domain_name;

        application myapp {
            ...
        }
    }
}

If NGINX is running in muti-processes mode and socket option SO_REUSEPORT is supported by platform, adding option reuseport for the directive listen will resolve the thundering herd problem.

rtmp {
    ...

    server {
        listen 1935 reuseport;
        ...
    }
}

Example configuration

worker_processes  1; #should be 1 for Windows, for it doesn't support Unix domain socket
#worker_processes  auto; #from versions 1.3.8 and 1.2.5

#worker_cpu_affinity  0001 0010 0100 1000; #only available on FreeBSD and Linux
#worker_cpu_affinity  auto; #from version 1.9.10

error_log logs/error.log error;

#if the module is compiled as a dynamic module and features relevant
#to RTMP are needed, the command below MUST be specified and MUST be
#located before events directive, otherwise the module won't be loaded
#or will be loaded unsuccessfully when NGINX is started

#load_module modules/ngx_http_flv_live_module.so;

events {
    worker_connections  4096;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    keepalive_timeout  65;

    server {
        listen       80;

        location / {
            root   /var/www;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        location /live {
            flv_live on; #open flv live streaming (subscribe)
            chunked_transfer_encoding  on; #open 'Transfer-Encoding: chunked' response

            add_header 'Access-Control-Allow-Origin' '*'; #add additional HTTP header
            add_header 'Access-Control-Allow-Credentials' 'true'; #add additional HTTP header
        }

        location /hls {
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }

            root /tmp;
            add_header 'Cache-Control' 'no-cache';
        }

        location /dash {
            root /tmp;
            add_header 'Cache-Control' 'no-cache';
        }

        location /stat {
            #configuration of streaming & recording statistics

            rtmp_stat all;
            rtmp_stat_stylesheet stat.xsl;
        }

        location /stat.xsl {
            root /var/www/rtmp; #specify in where stat.xsl located
        }

        #if JSON style stat needed, no need to specify
        #stat.xsl but a new directive rtmp_stat_format

        #location /stat {
        #    rtmp_stat all;
        #    rtmp_stat_format json;
        #}

        location /control {
            rtmp_control all; #configuration of control module of rtmp
        }
    }
}

rtmp_auto_push on;
rtmp_auto_push_reconnect 1s;
rtmp_socket_dir /tmp;

rtmp {
    out_queue           4096;
    out_cork            8;
    max_streams         128;
    timeout             15s;
    drop_idle_publisher 15s;

    log_interval 5s; #interval used by log module to log in access.log, it is very useful for debug
    log_size     1m; #buffer size used by log module to log in access.log

    server {
        listen 1935;
        server_name www.test.*; #for suffix wildcard matching of virtual host name

        application myapp {
            live on;
            gop_cache on; #open GOP cache for reducing the wating time for the first picture of video
        }

        application hls {
            live on;
            hls on;
            hls_path /tmp/hls;
        }

        application dash {
            live on;
            dash on;
            dash_path /tmp/dash;
        }
    }

    server {
        listen 1935;
        server_name *.test.com; #for prefix wildcard matching of virtual host name

        application myapp {
            live on;
            gop_cache on; #open GOP cache for reducing the wating time for the first picture of video
        }
    }

    server {
        listen 1935;
        server_name www.test.com; #for completely matching of virtual host name

        application myapp {
            live on;
            gop_cache on; #open GOP cache for reducing the wating time for the first picture of video
        }
    }
}