Migrate from NGINX-RTMP, support control module functionality.
winlinvip opened this issue · comments
The ControlModule provided by NGINX-RTMP is used to allow users to control system behavior, such as record, drop/kickoff, and redirect.
https://github.com/arut/nginx-rtmp-module/wiki/Control-module
TRANS_BY_GPT3
Drop/Kickoff has already been supported in SRS2, including kicking streams and kicking clients. Kicking streams is achieved through kicking the client that pushes the stream.
Reference: https://github.com/simple-rtmp-server/srs/wiki/v2_CN_HTTPApi#kickoff-client
TRANS_BY_GPT3
Record, also known as DVR, allows users to control when to start and stop recording. The configuration of DVR is written in a configuration file, but only provides APIs to enable and disable it.
TRANS_BY_GPT3
Redirect seems to be an alias, which may also include redirecting existing users to other vhosts without disconnecting the client. This feature seems to be less commonly used, as supporting new user Redirect should suffice.
TRANS_BY_GPT3
https://github.com/arut/nginx-rtmp-module/wiki/Directives#record
There is also a mention of the manual method.
TRANS_BY_GPT3
Let's summarize this issue again. The actual application scenario for the DVR API is as follows: Generally, DVRs are configured to record all streams of a specific vhost. However, in some cases, such as for broadcasters and monitoring purposes, all streams may need to be recorded, but only certain streams during specific time periods based on user requests.
NGINX provides an interface to control the DVR, which requires configuring the NGINX settings first.
rtmp {
server {
listen 1935;
application myapp {
live on;
recorder rec1 {
record all manual;
record_suffix all.flv;
record_path /tmp/rec;
record_unique on;
}
}
}
}
Configure the DVR in manual mode so that the streams are not recorded. Then, after calling the API, it will be possible to start and stop recording certain streams.
http://server.com/control/record/start|stop?srv=SRV&app=APP&name=NAME&rec=REC
There are two issues with the NGINX solution:
- It is inconsistent with the method of modifying files and then reloading. If the trigger is activated and the file is modified and reloaded, it becomes difficult to handle. The logic processing is more complex.
- After restarting, it is necessary to call the recording API again. This is a difficult aspect for NGINX to solve in terms of functionality.
On the other hand, SRS's approach is to modify the configuration and then reload, following the same model as implementing other functionalities. For example, the initial DVR configuration is as follows:
dvr {
apply off;
plan segment;
}
This is applied to streams that do not have any recordings, meaning they are not recording any streams. When there is a need to record a specific stream, the configuration is modified as follows:
dvr {
apply live/livestream;
plan segment;
}
Add the streams that need to be recorded to the "apply" section, then reload for the changes to take effect. Other parameters can also be modified. This approach avoids introducing new logic, prevents conflicts between the API and configuration, and the changes will still be effective after restarting. Essentially, it just adds a filtering condition to DVR without introducing new issues.
How does SRS support DVR API? In fact, there is no DVR API, but two APIs:
- An API that allows modifying the configuration and saving it to a file, which is equivalent to modifying the configuration.
- An API for reloading the configuration. Additionally, during the reload, it is possible to only reload a specific range, such as only the DVR for a particular vhost.
This way, DVR API can be implemented, and there can also be HLS API. Any functionality can be controlled through the API. In fact, SRS's control module is a superset of NGINX.
In other words, the DVR API of NGINX is implemented in this structure.
api/config-reload => dvr object
SRS does not change the unified configuration and reload model. The structure is as follows.
api => config-reload => dvr object
TRANS_BY_GPT3
#319 has already supported the RAW API, and with further enhancement of the DVR functionality, it will be able to support the control module of the DVR. Moreover, it can be made even more powerful. After server restart, the previous API calls will be remembered, meaning the server will keep track of which streams were recorded until they are cancelled.
TRANS_BY_GPT3
DVR adds a new configuration:
vhost dvr.srs.com {
dvr {
# the filter for dvr to aplly to.
# all, dvr all streams of all apps.
# <app>/<stream>, apply to specified stream of app.
# for example, to dvr the following two streams:
# live/stream1 live/stream2
# default: all
dvr_apply all;
}
}
At the same time, when reloading, dvr and dvr_apply should be reloaded separately so that modifying the DVR of one stream does not affect another stream.
TRANS_BY_GPT3
The calling format of the RAW API is as follows:
https://github.com/simple-rtmp-server/srs/wiki/v3_CN_HTTPApi#raw-dvr
https://github.com/simple-rtmp-server/srs/wiki/v3_EN_HTTPApi#raw-dvr
Example reference: http://ossrs.net:1985/console/ng_index.html#/summaries?host=ossrs.net&port=19851
TRANS_BY_GPT3
Note: Starting from version 4.0, the reload dvr_apply is no longer supported as it may cause issues. Please refer to https://github.com/ossrs/srs/pull/2282/files#r698879205 for more information.
This solution is not perfect, and in the future, it will be resolved using the HTTP API. Please refer to #2181 for more information.
TRANS_BY_GPT3
Can 'dvr_apply' support wildcards, for example, 'record/'?
vhost dvr.srs.com {
dvr {
# the filter for dvr to aplly to.
# all, dvr all streams of all apps.
# /, apply to specified stream of app.
# for example, to dvr the following two streams:
# live/stream1 live/stream2
# default: all
dvr_apply record/;
}
}
TRANS_BY_GPT3