Saltar a contenido

flv: Servidor de streaming de medios basado en nginx-module-rtmp

Instalación

Puedes instalar este módulo en cualquier distribución basada en RHEL, incluyendo, pero no limitado a:

  • RedHat Enterprise Linux 7, 8, 9 y 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 y Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-flv
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-flv

Habilita el módulo añadiendo lo siguiente en la parte superior de /etc/nginx/nginx.conf:

load_module modules/ngx_http_flv_live_module.so;

Este documento describe nginx-module-flv v1.2.13 lanzado el 23 de febrero de 2026.


nginx-http-flv-module workflow

Un servidor de streaming de medios basado en nginx-rtmp-module.

中文说明.

¡Dona si te gusta este módulo! ¡Muchas gracias!

PayPal

Características

Características nginx-http-flv-module nginx-rtmp-module Observaciones
HTTP-FLV (para reproducción) x HTTPS-FLV y respuesta en trozos soportados
Caché GOP x
Host Virtual x
Omitir directiva listen Ver observaciones Debe haber al menos una directiva listen
Soporte solo de audio para RTMP/HTTP-FLV Ver observaciones No funcionará si wait_video o wait_key está activado
Soporte de pista única para HLS x
Soporte reuseport x
Temporizador para registro de acceso x
Estadísticas estilo JSON x
Estadísticas para grabaciones x
Independiente de endianness Ver observaciones Soportado parcialmente en la rama big-endian

Sistemas soportados

  • Linux (recomendado) / FreeBSD / MacOS / Windows (limitado).

Reproductores soportados

Nota

Requisitos previos

  • GNU make para activar el compilador en sistemas similares a Unix para compilar software.

  • GCC para compilación en sistemas similares a Unix o MSVC para compilación en Windows.

  • GDB para depuración en sistemas similares a Unix.

  • FFmpeg o OBS para publicar flujos de medios.

  • VLC (recomendado) o flv.js (recomendado) para reproducir flujos de medios.

  • PCRE para NGINX si se necesitan expresiones regulares.

  • OpenSSL para NGINX si se necesita acceso cifrado.

  • zlib para NGINX si se necesita compresión.

Uso

Para detalles sobre el uso de nginx-rtmp-module, consulta README.md.

Publicar

Para simplificar, no se utiliza la transcodificación (por lo que se usa -c copy):

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

Nota

Algunas versiones antiguas de FFmpeg no soportan la opción -c copy, las opciones -vcodec copy -acodec copy pueden usarse en su lugar.

El appname se utiliza para hacer coincidir un bloque de aplicación en el bloque rtmp (ver más abajo para detalles).

El streamname puede ser especificado a voluntad pero NO puede ser omitido.

El puerto predeterminado para RTMP es 1935, si se utilizan otros puertos, :port debe ser especificado.

Reproducir

a través de HTTP-FLV

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

Nota

  • Si se utiliza ffplay en la línea de comandos para reproducir el flujo, la URL anterior DEBE estar entre comillas, o los argumentos en la URL serán descartados (algunos shells no tan inteligentes interpretarán "&" como "ejecutar en segundo plano").

  • Si se utiliza flv.js para reproducir el flujo, asegúrate de que el flujo publicado esté codificado correctamente, ya que flv.js soporta SOLO video codificado en H.264 y audio codificado en AAC/MP3.

El dir se utiliza para hacer coincidir bloques de ubicación en el bloque http (ver más abajo para detalles).

El puerto predeterminado para HTTP es 80, si se utilizan otros puertos, :port debe ser especificado.

El puerto predeterminado para RTMP es 1935, si se utilizan otros puertos, port=xxx debe ser especificado.

El valor de app (appname) se utiliza para hacer coincidir un bloque de aplicación, pero si el app solicitado aparece en varios bloques de servidor y esos bloques tienen la misma configuración de dirección y puerto, se utilizará la coincidencia del nombre de host con la directiva server_name para identificar el bloque de aplicación solicitado, de lo contrario, se coincide con el primero.

El valor de stream (streamname) se utiliza para hacer coincidir el nombre del flujo publicado.

Ejemplo

Supongamos que la directiva listen especificada en el bloque http es:

http {
    ...
    server {
        listen 8080; #no es el puerto predeterminado 80
        ...

        location /live {
            flv_live on;
        }
    }
}

Y la directiva listen especificada en el bloque rtmp es:

rtmp {
    ...
    server {
        listen 1985; #no es el puerto predeterminado 1935
        ...

        application myapp {
            live on;
        }
    }
}

Y el nombre del flujo publicado es mystream, entonces la URL de reproducción basada en HTTP es:

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

Nota

Dado que algunos reproductores no soportan la transmisión HTTP en trozos, es mejor especificar chunked_transfer_encoding off; en la ubicación donde se especifica flv_live on; en este caso, o la reproducción fallará.

a través de RTMP

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

a través de HLS

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

a través de DASH

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

Imágenes de muestra

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

RTMP & HTTP-FLV

HTTP-FLV (flv.js)

HTTP-FLV

Ejemplo nginx.conf

Nota

Las directivas rtmp_auto_push, rtmp_auto_push_reconnect y rtmp_socket_dir no funcionarán en Windows excepto en Windows 10 17063 y versiones posteriores, porque relay en modo de múltiples procesos necesita la ayuda de un socket de dominio Unix, consulta Unix domain socket on Windows 10 para más detalles.

Es mejor especificar la directiva worker_processes como 1, porque ngx_rtmp_stat_module puede no obtener estadísticas de un proceso de trabajo específico en modo de múltiples procesos, ya que las solicitudes HTTP se distribuyen aleatoriamente entre los procesos de trabajo. ngx_rtmp_control_module tiene el mismo problema. El problema se puede optimizar con este parche per-worker-listener.

Además, la característica vhost está bien en modo de un solo proceso pero no es perfecta en modo de múltiples procesos aún, esperando ser arreglada. Por ejemplo, la siguiente configuración está bien en modo de múltiples procesos:

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

        application myapp {
            ...
        }
    }
}

Mientras que la siguiente configuración no funciona correctamente para las solicitudes de reproducción destinadas al segundo server (ya sea que el puerto sea 1935 o no) de procesos de trabajo no publicadores:

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

        application myapp {
            ...
        }
    }

    server {
        listen 1945;
        server_name 2nd_domain_name;

        application myapp {
            ...
        }
    }
}

Si NGINX está ejecutándose en modo de múltiples procesos y la opción de socket SO_REUSEPORT es soportada por la plataforma, agregar la opción reuseport para la directiva listen resolverá el problema del "thundering herd".

rtmp {
    ...

    server {
        listen 1935 reuseport;
        ...
    }
}

Ejemplo de configuración

worker_processes  1; #debe ser 1 para Windows, ya que no soporta socket de dominio Unix
#worker_processes  auto; #desde las versiones 1.3.8 y 1.2.5

#worker_cpu_affinity  0001 0010 0100 1000; #solo disponible en FreeBSD y Linux
#worker_cpu_affinity  auto; #desde la versión 1.9.10

error_log logs/error.log error;

#si el módulo se compila como un módulo dinámico y se necesitan características
#relevantes para RTMP, el comando a continuación DEBE ser especificado y DEBE
#estar ubicado antes de la directiva de eventos, de lo contrario, el módulo no se cargará
#o se cargará sin éxito cuando NGINX se inicie

#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; #abrir streaming en vivo flv (suscribirse)
            chunked_transfer_encoding  on; #abrir respuesta 'Transfer-Encoding: chunked'

            add_header 'Access-Control-Allow-Origin' '*'; #agregar encabezado HTTP adicional
            add_header 'Access-Control-Allow-Credentials' 'true'; #agregar encabezado HTTP adicional
        }

        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 {
            #configuración de estadísticas de streaming y grabación

            rtmp_stat all;
            rtmp_stat_stylesheet stat.xsl;
        }

        location /stat.xsl {
            root /var/www/rtmp; #especificar dónde se encuentra stat.xsl
        }

        #si se necesita estadística estilo JSON, no es necesario especificar
        #stat.xsl pero una nueva directiva rtmp_stat_format

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

        location /control {
            rtmp_control all; #configuración del módulo de control de 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; #intervalo utilizado por el módulo de registro para registrar en access.log, es muy útil para depuración
    log_size     1m; #tamaño del búfer utilizado por el módulo de registro para registrar en access.log

    server {
        listen 1935;
        server_name www.test.*; #para coincidencia de sufijo comodín del nombre de host virtual

        application myapp {
            live on;
            gop_cache on; #abrir caché GOP para reducir el tiempo de espera para la primera imagen del 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; #para coincidencia de prefijo comodín del nombre de host virtual

        application myapp {
            live on;
            gop_cache on; #abrir caché GOP para reducir el tiempo de espera para la primera imagen del video
        }
    }

    server {
        listen 1935;
        server_name www.test.com; #para coincidencia completa del nombre de host virtual

        application myapp {
            live on;
            gop_cache on; #abrir caché GOP para reducir el tiempo de espera para la primera imagen del video
        }
    }
}

GitHub

Puedes encontrar consejos de configuración adicionales y documentación para este módulo en el repositorio de GitHub para nginx-module-flv.