Additional features for ngx_rtmp control module

[ArhiChief]

Hi.
Thanks a lot for continuing developing of this module.

This is not an error report, just a proposal to extend the functionality of control module.

There is derective like exec_static that makes avaliable to create a new publisher, but only at nginx startup. I think, it will be cool if you add publisher creation function to ngx_rtmp_control module, so we can create new transmissions via HTTP request.

[matiaspl]

I second your request. It would be nice not to have to write an app just to
spawn and keep running a few ffmpegs doing only stream copy from one rtmp
address to another.

Matt
21 kwi 2016 18:06 "Sergey Kosivchenko" notifications@github.com
napisał(a):

Hi.
Thanks a lot for continuing developing of this module.

This is not an error report, just a proposal to extend the functionality
of control module.

There is derective like exec_static that makes avaliable to create a
new publisher, but only at nginx startup. I think, it will be cool if you
add publisher creation function to ngx_rtmp_control module, so we can
create new transmissions via HTTP request.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#117

[sergey-dryabzhinsky]

This need to be properly handled to not start duplicates. May be by return codes.

Not in priority, sorry. Need to close other things.
But suggestions are welcome.

[misiek08]

For starting on-demand transcoding it will be better to write a separate daemon. I wrote 70-line node.js app and it does it's job. Due to rtmp nature and core of this module we work on single thread which need to handle all streaming work and I think separate daemon is better, because it takes additional work away from module allowing it to handle even bigger traffic.

[sergey-dryabzhinsky]

@misiek08 Good point.

[ArhiChief]

Thanks for response.
@sergey-dryabzhinsky. I think the request like GET http://<server_name>/publish/start|stop?app=<application_name>&stream=<new_stream_name>&addr=<location_of_restreaming_source> with response result similar to ngx_rtmp_control_module record function. It will start ffmpeg or avconv, or another program with params from request, i.e. ffmpeg -r <location_of_restreaming_source> -c copy -f flv rtmp://127.0.0.1/<application_name>/<new_stream_name>.

@misiek08, I don't have much expirience in such questions. Could you provide me any instructions on how you did it?

By the way, I can't run the ngx_rtmp_module in multiworkers configuration. If you need additional info, I'll be pleasured to provide it.

[lavvy]

Wow +1 for this feature
On Apr 22, 2016 9:03 AM, "Sergey Kosivchenko" notifications@github.com
wrote:

Thanks for response.
@sergey-dryabzhinsky https://github.com/sergey-dryabzhinsky. I think
the request like GET http:///publish/start|stop?app=&stream=&addr= with
response result similar to ngx_rtmp_control_module record function. It
will start ffmpeg or avconv, or another program with params from request,
i.e. ffmpeg -r -c copy -f flv rtmp://127.0.0.1// http://127.0.0.1//.

@misiek08 https://github.com/misiek08, I don't have much expirience in
such questions. Could you provide me any instructions on how you did it?

By the way, I can't run the ngx_rtmp_module in multiworkers configuration.
If you need additional info, I'll be pleasured to provide it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#117 (comment)

[misiek08]

RTMP protocol and this module implementation together don't work with multiple workers. There is push implementation, but it's buggy. I will provided node daemon code during weekend or maybe on Monday.

[ArhiChief]

@misiek08 is there any way to tell nginx to create 1 worker for rtmp and overs for http or other?

[misiek08]

I don't think it will work effective and be stable. I thought about closing listening socket but know I'm slowly switching off this module. RTMP is just pain in the ass and I'm switching for own, closed source solution to convert to HLS as close to streamer as possible :) This module still is great and very efficient, but author left it for working on commercial one and stopped supporting it. There are few core things that could be done slightly different way. In next few weeks I'll work more on this module code to fix all instability in newest nginx version to keep my existing instances working, but it's loosing sense.