Blog moving to blogspot

I’ve decided to move the blog to Google Blogspot. The new address is

nginx-rtmp.blogspot.com

It looks more consistent and much faster. Moreover wordpress.com is blocked by several major Russian ISPs.

.

Multi-worker statistics and control with nginx “per-worker-listener” patch

Today I’ve written a small nginx patch providing a feature that solves many problems in RTMP-HTTP integration namely statistics and control. Statistics and control is known to work bad in multi-worker mode since HTTP request goes to a random worker. So the client receives random worker statistics or performs a control action with a worker that didn’t receive previous actions from user.

The patch is named per-worker-listener. It can be downloaded here. When applied to nginx it opens ports for connecting to the worker you want, not just a random worker. Each worker has its own port number so you can choose the port to connect. The new syntax extends listen directive with a new option per_worker. The port specified in listen directive becomes base port number for worker listeners.

listen 80; # usual listen directive
listen 9000 per_worker; # per-worker listener

With the above configuration 1st worker will listen to 9000 port, 2nd to 9001 port, 3rd to 9002 port etc. To make that work please turn off accept_mutex. Listeners with no per_worker work as usual.

events {
    worker_connections  1024;
    accept_mutex off;
}

The patch is especially useful with stat and control handlers of nginx-rtmp-module.

server {
    listen   9000 per_worker;
    location /stat {
        rtmp_stat all;
        rtmp_stat_stylesheet stat.xsl;
    }
    location /stat.xsl {
        root /tmp;
    }
    location /control {
        rtmp_control all;
    }
}

Now see 3rd worker stats at the location http://localhost:9002/stat.

Windows support in 1.0.1

I’ve updated the nginx-rtmp code to compile and run on MS Windows. The limitations are

• execs are not supported
• static pulls are not supported
• auto_push is not supported

Moreover the code is now much more portable so it can probably compile on uncommon platforms not supported earlier.

UPD: Nginx for Windows compilation guide
Add RTMP module with the usual option –add=module=PATH/TO/nginx-rtmp-module

UPD2: You can use Microsoft Visual C++ 2010 Express to compile nginx. It’s free. Download it from Microsoft web site.

Secure links in nginx-rtmp

Many people ask me for secure link support in nginx-rtmp similar to nginx http secure links. The truth is no special support is needed to have that in nginx-rtmp. You can set secure links on on_connect, on_play or on_plubish. I’ll show how to do that for on_play. on_publish is very much the same, on_connect has no name argument, only app.

http {
    server {
        listen 8080;
        server_name localhost;

        location /on_play {

            # set connection secure link
            secure_link $arg_st,$arg_e;
            secure_link_md5 mysecretkey$arg_app/$arg_name$arg_e;

            # bad hash
            if ($secure_link = "") {
                return 501;
            }

            # link expired
            if ($secure_link = "0") {
                return 502;
            }

            return 200;
        }
    }
}
rtmp {
    server {
        listen 1935;

        # protected application
        application myapp {
            live on;
            on_play http://localhost:8080/on_play;
        }
    }
}

With the above configuration you cannot play any stream from myapp application without providing the right secure link.

> ffplay 'rtmp://localhost/myapp/mystream'
ffplay version 1.0.6 Copyright (c) 2003-2013 the FFmpeg developers
...
rtmp://localhost/myapp/mystream: Unknown error occurred

In error.log we have this message

notify: HTTP retcode: 5xx

Now let’s construct valid secure RTMP link. Get current timestamp first and add 1 hour expire time to it.

> date +%s
1370777449
> echo $((1370777449+3600))
1370781049

Then construct the hash (watch config above for key)

> echo -n "mysecretkeymyapp/mystream1370781049" | openssl dgst -md5 -binary | 
         openssl enc -base64 | tr '+/' '-_' | tr -d '='
Mbjev5ld4mmCN00mwIqD7w

Now we have the hash. It’s easy to construct the valid secure RTMP url.

> ffplay 'rtmp://localhost/myapp/mystream?e=1370781049&st=Mbjev5ld4mmCN00mwIqD7w'

Fixed build in nginx-1.5.1

According to nginx 1.5.1 changelist the bug with ssl requiring nginx-http_ssl_module when adding nginx-rtmp-module is now fixed. So nginx with nginx-rtmp-module should now build as before without any additional options. The bug has been introduced in 1.3.14. Thanks to Maxim Dounin for that fix.

VOD HLS in Nginx

Recently I have finished one project for Nginx Inc. The project is VOD HLS module making HLS stream from mp4 file. The module is fast and completely asynchronous. I think it is the fastest solution available. The module is easy to configure as well.

location / {
    hls;
    root /var/mp4;
}

Nginx VOD HLS module is proprietary. Please apply to Nginx Inc for more details.

VOD stat in 0.9.20

I’ve merged VOD statistics into master. Now you can see it on /stat page.

Optional HLS cleanup

Today I’ve added a new directive hls_cleanup toggling HLS fragment and playlist cleanup from nginx cache manager process. By default cleanup is on. Now you can turn it off and have plain MPEG-TS chunked recorder.

application myapp {
    live on;
    hls on;
    hls_path /tmp/hsls;
    hls_cleanup off;
}

Simple pull/push DNS load-balancing in 0.9.19

Simple DNS load-balancing is implemented in 0.9.19. When remote host name is resolved to multiple addresses then stream is pulled or pushed sequentially from all those addresses.

application myapp {
    live on;
    pull rtmp://video.example.com/someapp;
}

Suppose video.example is resolved to 192.168.0.1 and 192.168.0.2. When the first server is unavailable the next connection attempt will be made to the second server.

Dynamic pull and push in 0.9.19

Since 0.9.19 version of nginx-rtmp-module you can dynamically pull or push streams with on_play and on_publish. 3xx HTTP result code used to redirect current stream. Now if the new stream name is started with rtmp:// then it’s supposed to be RTMP URL and relay (pull/push) is created for the current client.

http {
    ...
    location /local_redirect {
        rewrite ^.*$ newname? permanent;
    }
    location /remote_redirect {
        # no domain name here, only ip
        rewrite ^.*$ rtmp://192.168.1.123/someapp/somename? permanent;
    }
    ...
}

rtmp {
    ...
    application myapp1 {
        live on;
        # stream will be redirected to 'newname'
        on_play http://localhost:8080/local_redirect;
    }
    application myapp2 {
        live on;
        # stream will be pulled from remote location
        # requires nginx >= 1.3.10
        on_play http://localhost:8080/remote_redirect;
    }
    ...
}

In the example above myapp1 uses old redirect behavior, myapp2 shows the new feature.

In myapp2 application source stream name is not changed and pull is created for the source stream name. Later clients connecting to this stream will see the video pulled by the first client. That’s identical to usual pull behavior. You can change it however by specifying notify_relay_redirect on. This will redirect pulled stream to a new (long url-like) local name. So the streams will be grouped on rtmp url.

on_publish does the same for push operation.

The feature has 2 limitations

• RTMP URL should not contain domains names, only IP addresses
• nginx version>=1.3.10 is required