Version Query API: The official website provides an API to query the latest stable version. SRS logs prompt for an upgrade.

[winlinvip]

The current version release of SRS is available on the official website ossrs.net and tags. The version information is divided into:

• Version number, such as 3.0.161, corresponds to the installation package SRS-CentOS7-x86_64-3.0.160.zip. The program also prints this version number, for example, ./objs/srs -v.
• Release abbreviation, such as v3.0-r4, corresponds to the release information in CHANGELOG, as well as the Docker image ossrs/srs:v3.0-r4.
• Stable version and development version, for example, currently 4.0 is being released and there is no released version yet, such as 4.0.123, corresponds to the Docker image ossrs/srs:v4.0.123.

So here comes the question:

• Which version is recommended? 2.0, 3.0, or 4.0?
• I am currently using 2.0, can I upgrade to 3.0 or 4.0?
• I am using 4.0, but even the development version is unstable, should I upgrade?

This needs to be queried through the official website's API in order to provide a better answer in the program or webpage.

1. The SRS official website can provide a version query API to check the latest released version.
2. When starting SRS, access the version query API and log a message if the version is not the latest.
3. Every hour, access the version query API to check for updates.
4. Provide a configuration option to disable the version query feature, which is enabled by default.

API

The SRS official website provides an API to query version information, defined as follows:

HTTP/HTTPS GET https://api.ossrs.net/service/v1/releases?version={version}&ts={timestamp}

Request parameters:

• version: The current version of your SRS, such as v2.0.266, v3.0.160, or v3.
• ts: Timestamp to prevent GET caching, simply use the current system time. For example, in JavaScript, you can call the function new Date().getTime().

Response data is a JSON object with the following fields:

• match_version: The best matching version, recommended to upgrade to this version. For example: v2.0.272
• match_docker: The best matching Docker image, can be upgraded to this image's TAG. For example: v2.0-r8
• match_docker_image: The best matching Docker image address, can be directly run with Docker. For example: ossrs/srs:v2.0-r8
• match_docker_mirror: The best matching Docker acceleration address, faster than the Docker official mirror on Alibaba Cloud in China. For example: registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v2.0-r8
• stable_version: The current stable version, recommended for production use. For example: 3.0.161
• stable_docker: The TAG of the current stable version's Docker image. For example: v3.0-r5
• stable_docker_image: The address of the Docker image for the current stable version, can be directly run. For example: ossrs/srs:v3.0-r5
• stable_docker_mirror: The acceleration address for the current stable version on Alibaba Cloud, faster than the Docker official mirror. For example: registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v3.0-r5

For example, if you don't have SRS and want to know which version to use, you can directly request this API:

https://api.ossrs.net/service/v1/releases

Response
{
"match_version": "3.0.161",
"stable_version": "3.0.161"
}

• Both match_version and stable_version are stable versions 3.0.161.

For example, if you are running SRS 2.0, SRS will request this API:

https://api.ossrs.net/service/v1/releases?version=v2.0.266

Response
{
"match_version": "2.0.272",
"stable_version": "3.0.161"
}

• match_version: The best matching version, which you are currently running is v2.0.266, and there is a stable version v2.0.272 available, recommended for upgrade.
• stable_version: The current stable version is v3.0.161, and you can also choose to upgrade to this version. Note that there is no version 4.0, so it is not recommended to upgrade to 4.0.

For example, if running SRS 4.0, the request and response are as follows:

https://api.ossrs.net/service/v1/releases?version=v4.0.120

Response:
{
"match_version": "v4.0.123",
"stable_version": "3.0.161"
}

• match_version: The best match is v4.0.123. Although this version is not as stable as 3.0, downgrading is not recommended. Therefore, it is recommended to upgrade to 4.0 instead of 3.0.
• stable_version: The current stable version is 3.0.161, but downgrading to 3.0 may result in unsupported features, so careful consideration is advised.

Config

Configuration method, default enabled:

# Query the latest available version of SRS, write a log to notice user to upgrade.
# @see https://github.com/ossrs/srs/issues/2424
# Default: on
query_latest_version on;

TRANS_BY_GPT3

[winlinvip]

Prepare to disable this feature for two reasons:

1. As an open-source streaming server, SRS should not collect any usage information, including IP addresses and features.
2. As an open-source community, we do not need to know which features are popular. In fact, we are willing to support all features as long as developers are willing to submit patches.
3. As developers ourselves, we can submit patches based on our own desires, as long as we adhere to the developer guidelines, without needing to base the decision to develop a certain feature on how much it is used.

Taking the support for the RTSP protocol as an example, initially, we did not support RTSP because internet live streaming primarily used RTMP and HLS. However, embedded devices and cameras preferred RTSP. Of course, now many are starting to support the WebRTC protocol, such as Google cameras.

As the project evolved, the community began to provide feedback on the need for RTSP support, so we added this feature. Later, we discovered that security cameras in China do not actually push RTSP streams, rendering our support ineffective. Consequently, we shifted our focus to supporting the GB protocol. I have detailed the reasons for this update in issue #2304.

In fact, as we deepened our understanding of the business, we realized that some older drones support RTSP streaming. Of course, newer drones have started to support WebRTC streaming. However, this does not necessarily mean that we have decided to support RTSP streaming.

What I want to convey is that the open-source community does not need to decide on supporting a feature based solely on the number of users utilizing it. In fact, the needs of even a minority can be of great value. Sometimes, niche requirements also need to be supported.

Therefore, we no longer need to proactively report on feature usage to determine which features SRS will support in the future, so we will disable reporting by default. #3990

TRANS_BY_GPT4