DVR: Obtain complex recording rules for a specific stream from the API, with dvr_apply being the fixed rule.

[houxuexianhan]

Description

dvr_apply does not support wildcards. When dvr_apply is configured for a specific stream, the custom output file path does not take effect.

1. SRS Version: v3.0.155
2. SRS Log:

(Note: Please provide the actual logs for accurate translation)

xxxxxxxxxxxx

Config for SRS:

Please provide the specific configuration for SRS.

 dvr{
  	enabled         on;
	dvr_apply	dvr/a
	dvr_path	/var/www/html/[app]/[stream].[2006][01][02][15][04][05][999].mp4;
	dvr_plan	session;
	dvr_duration	30;
	dvr_wait_keyframe       on;
	time_jitter             full; 
    }

Expected Behavior

It is desired to have support for wildcard configuration like live/* in dvr_apply.
Once dvr_apply is configured for a specific stream, the recording file path should be effective according to dvr_path.

TRANS_BY_GPT3

[robertluoxu]

I hope the DVR path can support online OSS storage.

TRANS_BY_GPT3

[winlinvip]

Regarding supporting cloud storage, refer to #1193.

Hope the DVR path can support online OSS storage.

TRANS_BY_GPT3

[winlinvip]

Previously, it was accomplished through configuring dvr_apply, but this method cannot handle complex matching and is only suitable for fixed rule matching, which is prone to problems #2282.

For complex matching, such as wildcard or dynamic adjustment needs, it is better to call the HTTP API to determine whether to record a certain stream, for example:

dvr_filter http://xxx

Note: Please note that this dvr_filter needs to be implemented by your own service, not by SRS.

By requesting this API, it returns whether to record this stream and some necessary configurations.

This way, you don't have to rely on SRS to perform complex recording logic.

TRANS_BY_GPT3

[lxge]

dvr_filter

Hello, may I ask how to dynamically configure 4.0, adjust the recording time period? After calling the raw API and getting a return code of 0, there is no actual effect.

TRANS_BY_GPT3

[guoronghui]

4.0 no longer supports RAW API recording, right?

TRANS_BY_GPT3

[winlinvip]

Essentially, what everyone wants is dynamic recording, where they can decide whether or not to record the stream and how to do it based on their own business needs.

The RAW API can only achieve very limited capabilities and has many issues, which is why this solution has been removed.

The alternative solution is a dynamic Forward-like approach, which can be referenced at: #1342

Dynamic Forward support has been quickly implemented and dynamic DVR will be done in the future.

TRANS_BY_GPT3

[winlinvip]

Dup to #1577

Duplicate Issue, I have closed this one.

TRANS_BY_GPT3

[danielamar101]

The alternative solution is a dynamic Forward-like approach, which can be referenced at: #1342

so essentially @winlinvip you are saying to have an auxiliary SRS process that upon an on_forward hook trigger we return:

    forward_stream = {
        "urls": [
            f"rtmp://127.0.0.1:1935/output/live{param}", <-- first SRS process
            f"rtmp://127.0.0.1:1936/output/live{param}" <-- second SRS process with DVR enabled
        ]
    }

And this second SRS process with DVR enabled can be reloaded to record for exactly the length required in essence? This way the state of the "master" SRS process will never be reloaded,Which I can forsee causing alot of issues if we had to reload this everytime, and the "slave" SRS process with the sole purpose of recording can be configured on the fly?

This is the solution I have in mind that should fulfill my usecase.