Config: Support app level configuration to compatible with Nginx.

[zh19900725]

What is the business background? Please provide a description.
Assuming the same data stream, I need to expose FLV and RTMP to the client. For example, if I push /live/123456 to SRS, the generated links would be http://127.0.0.1:8080/live/test.flv and rtmp://127.0.0.1:1935/live/test.

Is your feature request related to a problem? Please describe.
When deploying with Kubernetes in a containerized environment, I must assign a domain name to the playback link. During the configuration of Ingress or Services, because RTMP and FLV use different ports, I cannot route the root path /live to both ports. Consequently, I am forced to apply for two separate domain names. This results in each playback protocol having a different domain name, making the configuration difficult to maintain.

Describe the solution you'd like
Is it possible to generate different routing rules for the same stream?

Describe alternatives you've considered
For instance, if I do not specify an app, can the system automatically use the deviceId and protocol name as the app? When I push stream 123456 to SRS, it automatically generates:
/[deviceId]flv/123456.flv
/[deviceId]rtmp/123456
This way, only one domain name is needed, and based on routing, it can be forwarded to different playback ports.

Additional context
Add any other context or screenshots about the feature request here.

TRANS_BY_GPT4

[winlinvip]

This requirement is very reasonable; it is currently based on the configuration of hosts, for example:

vhost a.mydomain.com {
    origin server-a;
}
vhost b.mydomain.com {
    origin server-b;
}

Indeed, if support for app-level configuration is provided, it could be transformed into:

vhost __defaultVhost__ {
  location /a {
      origin server-a;
  }
  location /b {
      origin server-b;
  }
}

Since Nginx supports both methods, and often the location directive is used more frequently, the configuration when Nginx proxies back to SRS is quite similar. However, for stream pushing, SRS only supports vhost configuration, which indeed can be more cumbersome to use.

Unfortunately, this change is significant and difficult to support in the short term.

Workaround: You can have the downstream traffic such as HTTP-FLV or HLS go through an Nginx proxy once, which then reverse proxies to different SRS ports or virtual hosts. For publish streaming, on the SRS Edge, you can still only use ports or virtual hosts to achieve sourcing from different SRS instances.

TRANS_BY_GPT4

[winlinvip]

Keep it open, please.