changing application-section on the fly

[Martin Veltins]

Hi there,

I'm sending different rtmp streams to my server, which are handled greatly by the rtmp module.

Sometimes though i need to add / remove streams (applications)  to / from the server
Therefore i wanted to change the nginx.conf on the fly, using something like this: http://snippets.aktagon.com/snippets/93-change-nginx-configuration-on-the-fly
Using that, nginx seems to use the new config file, but sadly, all active streams stop right ahead.

Some googling pointed me to the http control module, which is able to stop / start streams.
This could come handy sometimes, but does not seem to be enough for me here.

I need to (more or less) dynamicaliy add new excec commands, change max. lenght / frames of some streams (online / offline), activate / deactivate audio / video ... .
(in this thread: https://groups.google.com/forum/#!topic/nginx-rtmp/QIzG1E6AQew i asked for beeing able to change the applications name dynamicaly,
this is not necessary anymore, but changing the application's behavior is)

Could it perhaps be possible to alter nginx at some place to make it read the config file and only do something to / with a stream when there was a change within that stream's application-section?
If not, do you know a work around?

Thanks once again!
Martin

[Stephen Basile]

In my company's fork of nginx-rtmp, I implemented an on the fly configuration system that operates by parsing the response body received by on_publish directive.  This allows me to pass in config options on a per stream level for all of the options that matter for my use case.  My code would not be specifically useful for you because I didn't do anything with exec, but it might be an idea worth exploring if you're willing to write some code.

[Martin Veltins]

Your company's fork isn't public, is it? :)

This sounds like a huge step for me to take, problem is, i'm willing to write some code, but i don't have the capabilities to do so .... .

I thought the rtmp module would be used on 'a lot' of productive systems (e.g. http://rarut.wordpress.com/2013/03/06/vimeo-is-using-nginx-rtmp/ ) , how comes it's still missing this feature?
Am i wrong, or isn't this an important feature for systems, where you have > 10 applications?
If there's a setup with let's say 10 apps, there could be 100 streams, which have to be 'killed' in order to make one (little)  change, doesn't sound right to me .... .

I appreciate your idea, but i hope there's a more easier way to accomplish that, perhaps Roman Arutyunyan has one? :)

Thanks!
Martin

[Roman Arutyunyan]

There's no way to change configuration dynamically. Nginx used to support dynamic config reload, but it's not a solution for rtmp.

There's no much sense in adding that to the rtmp module.

If you want to add more execs then just execute a script which will run child processes you can control.

--
You received this message because you are subscribed to the Google Groups "nginx-rtmp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nginx-rtmp+...@googlegroups.com.
Visit this group at http://groups.google.com/group/nginx-rtmp.
For more options, visit https://groups.google.com/d/optout.

--
--

Roman Arutyunyan

[Martin Veltins]

Thanks for your answer Roman,

what exactly do you mean by a script, running a child process, i can control?
Do you mean something like an excec in the nginx.conf(rtmp, app), which starts an other script, that handels different excecs?
That's one option for delivering different streams to different devieces, but what about things like that?:

record audio or not,
change recording_path,
set HLS fragment size, HLS path,
set different reocrd_max_frames or max. file size
Add a new HLS/what ever application, without killing activ streams?
..... .

To me it looks like these things are fully under control of nginx.conf, like there's no other way to handle them, am i wrong?

If not, what about making the module reload it's config, without crashing existing streams?
I mean, if there was no change within a stream's application or that stream was active a the time reloading, that stream could be handled like nothing happend.
Or move part of the module into a database, which makes it even more dynamical! :)

I don't know if that's possible, this is just a simple 'idea' of mine, how to improve this greate module!

Thanks again,
Martin

[Reuben Martin]

On Tuesday, July 22, 2014 5:52:14 AM UTC-5, Martin Veltins wrote:

what exactly do you mean by a script, running a child process, i can control?
Do you mean something like an excec in the nginx.conf(rtmp, app), which starts an other script, that handels different excecs?
That's one option for delivering different streams to different devieces, but what about things like that?:

You need to get used to the idea of a nested scheme when setting up the application blocks. You have a "Viewer" application that pullls from a "Switcher" Applications. That "Switcher" Application has channels that pull from different "Source" Applications. By redirecting to different channels in the "Switcher" Application, you are in effect jumping between different "Source" Applications.

Now this isn't the same as dynamically creating and destroying application blocks on the fly, but applications are just a means of grouping streams with with the same properties / settings. Usually any properties or settings are a known quantity and you can set up as many "Source" Applications as needed and then dynamically create streams in those Application that are pulled in by the "Switcher" application.

[Martin Veltins]

Hm, ok, I'm trying to understand this, do you mind giving me a small example of those applications? :)
(Especially the 'swticher' one)

Usually any properties or settings are a known quantity

You're are right, i guess, i can think about most of those settings and integrate them right at the start up.

[Reuben Martin]

On Thursday, July 24, 2014 5:15:47 AM UTC-5, Martin Veltins wrote:

Hm, ok, I'm trying to understand this, do you mind giving me a small example of those applications? :)
(Especially the 'swticher' one)

Ok, this is quick and dirty and leaves out some things for the sake of clarity...

Within the http config block make sure you have a control interface defined.

location /control {
    rtmp_control all;
} code here...

Then in the rtmp block a structure similar to something like this:

application publish {
    live on;
    wait_key on;

    pull rtmp://127.0.0.1/switcher/foo name=view;
}


application switcher {
    live on;
    wait_video on;

    pull rtmp://127.0.0.1/foo/stream-A name=foo static;
    pull rtmp://127.0.0.1/bar/stream-B name=bar static;
}

application foo {
    live on;
}

application bar {
    live on;
}

A player connects to rtmp://hostname/publish/view

The resulting stream ends up being from whatever is being published to rtmp://hostname/foo/stream-A

Using the control interface you can redirect the pull within the switcher app, resulting in the stream being redirected to what is published to rtmp://hostname/bar/stream-B

https://github.com/arut/nginx-rtmp-module/wiki/Control-module
http://nginx-rtmp.blogspot.com/2014/01/redirecting-streams-in-version-111.html

Note that if you are going to be redirecting between streams in the switcher app, make sure you keep the GOP size in the encoded streams low, or you will end up with significant delays that cause problems due to timing out. (The switch needs to happen on I frames)