Support RAW API, support read/write API, which means support calling the http API to modify configuration and reload.

[winlinvip]

!!! Attention, the RAW API has been disabled after version 4.0, please refer to #2653 for background information.

!!! RAW API is removed from SRS 4.0, please see #2653

Other than the ability to reload, all other RAW API capabilities have been removed.

Provide an HTTP API to modify the configuration file and then reload the effective configuration.
https://github.com/winlinvip/simple-rtmp-server/issues/319

TRANS_BY_GPT3

[winlinvip]

API support writing is the foundation of many functionalities. API security (#470) is the foundation of support writing.

TRANS_BY_GPT3

[winlinvip]

See #459

[winlinvip]

There are two options:

1. Similar to nginx, provide a manual DVR method that can be triggered by an API.
2. Provide an API for configuring DVR by modifying the configuration file and then reloading to start recording.

The first option, like nginx, has a significant impact on the current structure and is inconsistent. The second option would not have much impact, as it only provides configuration writing.

I believe it is necessary to trigger DVR using an API, otherwise all streams of a channel would be recorded continuously, which is not suitable. Especially for applications with certain types of broadcasters or monitoring, it would be more effective to only record streams during certain time periods.

Some can be differentiated based on vhost, where a vhost with DVR would be used for streams that need to be recorded, while a vhost without DVR would be used for those that do not need to be recorded.

In reality, using an API to control DVR is primarily intended for situations where all streams may potentially need to be recorded, but not all of them actually need to be.

TRANS_BY_GPT3

[winlinvip]

So if we choose to implement solution two, it will not disrupt the existing structure, ensure overall consistency, and not introduce new structures. It will be in line with HTTP RESTful API. I feel that this can be added.

TRANS_BY_GPT3

[winlinvip]

The NGINX solution has two issues:

1. It is not consistent with the method of modifying and reloading files. If it is triggered and then the file is modified and reloaded, it becomes difficult to handle. The logical processing is more complex.
2. After restarting, the recording interface needs to be called again. This is a difficult issue to resolve with NGINX's dvr API.

In other words, NGINX's dvr API implements 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

In other words, it can actually be achieved by modifying the configuration and then reloading. For example, if you want to record a certain livestream flow, modify the configuration file:

dvr {
    apply live/livestream;
}

Then, the reload will only record that flow.

The API simply provides a way to modify the configuration file and then reload it; it is the same as directly modifying the configuration and reloading it through the console. This avoids the need for additional mechanisms in nginx to implement this functionality.

TRANS_BY_GPT3

[winlinvip]

This also has a very important application, which can manage servers through the console. Adding channels and features can all be done directly through the interface, with many prompts and validations available.
This feature is very useful for configuration systems. Previously, configuration systems had to parse the configuration files themselves. In fact, the entire configuration can be completed through an HTTP API. Simply send an HTTP request. This actually saves the workload of external systems.

TRANS_BY_GPT3

[wenjiegit]

I recommend reloading the affected vhost, following the principle of minimizing impact.

TRANS_BY_GPT3

[winlinvip]

I will first add a signal, SIGUSR1, which can write the configuration to a file. SIGUSR2 is already used, it simulates SIGINT to allow the system to clean up and exit, and check for memory leaks.

killall -s SIGUSR1 srs
killall -30 srs

Both can make SRS write the configuration to the configuration file.
https://github.com/simple-rtmp-server/srs/wiki/v3_CN_HTTPApi#persistence-config
https://github.com/simple-rtmp-server/srs/wiki/v3_EN_HTTPApi#persistence-config

TRANS_BY_GPT3

[winlinvip]

An example of writing a configuration file:

winlin:srs winlin$ cat test.conf 
listen 1935;
max_connections 1000;
daemon off;
srs_log_tank console;
pithy_print_ms 1000;
http_api {
    enabled on;
    listen 1985;
}
http_server {
    enabled on;
    listen 8080;
}
stream_caster {
    enabled off;
    caster flv;
    output rtmp://127.0.0.1/[app]/[stream];
    listen 8936;
}
vhost __defaultVhost__ {
    exec {
        enabled on;
        publish ./objs/ffmpeg/bin/ffmpeg -f flv -i [url] -c copy -y ./[stream].flv 1> /dev/null 2>/dev/null;
    }
    hls {
        enabled off;
        hls_fragment 1;
        hls_window 10;
        hls_wait_keyframe off;
    }
}

TRANS_BY_GPT3