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

TRANS_BY_GPT3

See #459

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

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

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

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

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

TRANS_BY_GPT3

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

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

I changed this feature to RAW API, which means reading from and writing to the API. It allows for easier communication with simpler vocabulary.

TRANS_BY_GPT3

https://github.com/simple-rtmp-server/srs/wiki/v3_CN_HTTPApi#raw-update
https://github.com/simple-rtmp-server/srs/wiki/v3_EN_HTTPApi#raw-update
API for updating configurations. After calling the API, the corresponding configuration can be directly reloaded into memory; then the modified configuration will be saved as a configuration file. SRS does not update the file first and then reload, but uses a more efficient and accurate method to reload into memory.

TRANS_BY_GPT3

The HTTP RAW API with global configuration has been completed. Demo address: http://ossrs.net/console/ng_index.html#/configs?host=ossrs.net&port=19851.

TRANS_BY_GPT3

Adding, deleting, disabling, enabling, and modifying the name of Vhost have all been completed.
https://github.com/simple-rtmp-server/srs/wiki/v3_CN_HTTPApi#raw-vhost
https://github.com/simple-rtmp-server/srs/wiki/v3_EN_HTTPApi#raw-vhost

TRANS_BY_GPT3

The RAW API is supported up to this point, more detailed API will need to be added later.

TRANS_BY_GPT3

#459 NGINX style DVR control module, can be done on the RAW API, and can be made more powerful. After the server restarts, it will remember the last API call, that is, the server will continue to remember which streams were recorded until canceled.

TRANS_BY_GPT3

Compared to raw API, integrating Lua and providing Lua instructions might be better.

TRANS_BY_GPT3

Extending the language is too troublesome, it's not a good thing.

TRANS_BY_GPT3

SIGUSR1 is used for log rotate in nginx, and has been corrected. Persistence log does not rely on signals, only through API support.
Reference: 2955b1f

TRANS_BY_GPT3

Writing CONFIG to a file is the best approach for a configuration file system. Another alternative is to not use a configuration file for dynamic configuration (only configuring the API server address in the configuration file) and obtain dynamic configurations through API.

TRANS_BY_GPT3

If recording functionality is enabled in Docker, the Docker container exits as soon as the recording is started. Is there any workaround to bypass this mechanism and prevent the Docker container from exiting upon restarting SRS? Or do I have to give up Docker and choose another option?

TRANS_BY_GPT3

Why does recording cause Docker to exit?

TRANS_BY_GPT3

Is there still no API in cooperation with ingest within the vhost?

TRANS_BY_GPT3