Thursday, April 3, 2014

Proxy Protocol support in nginx-rtmp-module 1.1.4

The new version of nginx-rtmp-module has proxy protocol support added. Proxy protocol lets you put nginx behind a TCP-proxy and still have real client address. Here's an example of nginx.conf setting a listener with proxy protocol enabled.
rtmp {
    server {
        listen 1935; # usual listener
        listen 1936 proxy_protocol; # handles proxy protocol
        
        application myapp {
            live on;
        }
    }
}
If proxy_protocol option is specified in listen directive, such listener expects proxy protocol header from its client before RTMP data and will not handle plain RTMP requests. The client address received via proxy protocol is used everywhere instead of the proxy address including logs and on_XXX callbacks.

Notable software having client-side proxy protocol support allowing you to proxy RTMP requests to nginx-rtmp-module:

Monday, January 13, 2014

RTMP play2 support in version 1.1.2

In nginx-rtmp-module version 1.1.2 play2() support is added. Some players use this call to switch to a different stream or bitrate.

Sunday, January 12, 2014

New exec_record_done variables

New variables are added to exec_record_done directive to make setting files and directories easier.
  • filename - file name portion of the path, directory omitted
  • dirname - directory path
  • basename - file name with file extension omitted

Assume path is /tmp/rec/mystream-1389499351.flv. Then filename is mystream-1389499351.flv, dirname is /tmp/rec, basename is mystream-1389499351.

Example of recording mp4 with proper file names.
application myapp {
  live on;
  record all;
  record_path /tmp/rec;
  record_unique on;
  record_interval 30s;
  exec_record_done ffmpeg -i $path -c copy /var/videos/$basename.mp4;
}
Wiki is updated as well.

Friday, January 10, 2014

Redirecting streams in version 1.1.1

In version 1.1.1 of nginx-rtmp-module stream redirect feature is added. Now you can change currently played or published stream in realtime through control request. The following call changes subscriber stream name to newname. The subscriber is found in myapp application by the IP address 127.0.0.1.
http://server.com/control/redirect/subscriber?app=myapp&addr=127.0.0.1
&newname=newname
The above example changes stream for a single client. To change it for all clients use pull and change its source end. You can pull certain streams from VOD applications as well.
application myapp {
  live on;
  hls on;
  hls_path /var/hls;
  pull rtmp://localhost/src/default name=myapp static;
}

application src {
  live on; 
  pull rtmp://localhost/vod/title.mp4 name=default;
  pull rtmp://localhost/vod/ad.mp4 name=ad;
}

application vod {
  play /var/videos;
}
The myapp stream starts with title.mp4. Now switch to cam1 (which should be published to src application)
http://server.com/control/redirect/subscriber?app=src&addr=127.0.0.1
&newname=cam1
Now show ad.mp4
http://server.com/control/redirect/subscriber?app=src&addr=127.0.0.1
&newname=ad
Back to cam1
http://server.com/control/redirect/subscriber?app=src&addr=127.0.0.1
&newname=cam1
Now show cam2
http://server.com/control/redirect/subscriber?app=src&addr=127.0.0.1
&newname=cam2
The new stream starts immediately in RTMP. In HLS the stream is usually slightly delayed due to the nature of HLS.

Limitations:
  • The feature only works in single-worker mode. You can easily create a streaming backend with a single worker to pull from.
  • MPEG-DASH engine cannot handle stream discontinuities so the feature will not work properly with DASH

Tuesday, January 7, 2014

Notify relay redirect name hashing

In latest master I implemented name MD5 hashing when notify_rely_redirect on is used. In previous versions remote URL was used as new stream name in this case. That introduced problems with recording and HLS/DASH since such names may not be permitted as file names.

Sunday, December 29, 2013

Happy streaming in 2014!

My son Andrew


Thanks to Adrian Drzewicki (webina.rs project) for the amazing t-shirt.

One common exec issue

I'm often asked to help with exec directive not starting child ffmpeg (or any other process). One common error is the following

  • ffmpeg is NOT in /bin or /usr/bin
  • full path is not specified in exec, only binary name

In this case exec will not start child process because nginx wipes its environment before starting workers. So child processes have empty PATH variable and cannot find the executable. In such cases the binary is usually looked up in default locations like /bin or /usr/bin.

To solve the issue please add env PATH directive to nginx.conf. It will preserve PATH environment variable.


...
# keep $PATH
env PATH;
...

rtmp {
  server {
    listen 1935;
    application myapp {
        live on;
        exec ffmpeg -i rtmp://localhost/myapp/$name
                    -c copy -f flv rtmp://localhost/app2/$name;
    }
    application app2 {
      live on;
    } 
  }
}