HTTP-FLV: Play a stream with no data, no timeout or 404, or the player waits

[RocFang]

Branch: 2.0

@winlinvip hi,

First of all, currently in srs2.0, there is a timeout disconnection handling for the publishing end, but there is no related handling for the player. This is considered another issue, and it is mentioned here just as an introduction.

In the case of RTMP, this is not surprising. However, when providing HTTP-FLV services, the usual scenario is to proxy through Nginx to SRS. At this time, Nginx has a proxy_read_timeout configuration, whether it is default or custom. In intuitive logic, there is a timeout disconnection for the player through Nginx proxy, and this situation is indeed valid for the SRS origin server.

However, when SRS serves as an edge server for HTTP-FLV, the behavior can be a bit "unexpected". In order to implement the reduce_sequence_header feature, SRS does not clean up the cache_metadata, cache_sh_audio, and cache_sh_video when unpublishing. The edge ingester triggered by the HTTP-FLV player on the edge SRS will keep retrying due to the absence of a stream from the origin server, and each retry will resend the metadata and sequence header obtained from the origin server to the client. As a result, from the perspective of the HTTP-FLV player, even though there is no actual stream, the edge ingester keeps sending this data to Nginx at the interval of the edge ingester's timeout. This makes it seem like the proxy_read_timeout is not working as expected, unless a very small proxy_read_timeout is set, otherwise the connection will remain open indefinitely.

TRANS_BY_GPT3

[winlinvip]

Clearing the cache when the encoder stops streaming is reasonable.

TRANS_BY_GPT3

[RocFang]

How was the lack of a timeout disconnect mechanism considered when playing rtmp?

TRANS_BY_GPT3

[winlinvip]

Should support configuring read timeout.

TRANS_BY_GPT3

[winlinvip]

How was the lack of timeout disconnection mechanism considered when playing rtmp?

It is handled simply. This issue is a bit complex. RTMP playback and streaming are not coupled, so playback can still happen even without streaming. However, in HTTP, if there is no streaming, the resource does not exist, so it should return a 404 error.

However, HTTP can also trigger origin retrieval, so when there is no stream, playback can trigger the retrieval of the stream (streaming). When streaming stops, at this point, the HTTP handler should be disabled, which means according to HTTP logic, it should return a 404 error.

Unless HTTP completely abandons the use of 404, like RTMP does not need to handle "unpublish", but this approach is quite unreasonable. The more reasonable approach is to still introduce the concept of 404. Triggering origin retrieval should be an independent mechanism, but if "unpublish" occurs after origin retrieval, it should still be treated as a 404 error.

In other words, if RTMP has the concept of 404 and returns an error when the stream does not exist, it will disconnect the player connection when "unpublish" occurs. Of course, triggering origin retrieval in RTMP is an independent mechanism and is unrelated to this.

Looking back at player timeout, it refers to the timeout when there is no stream for a certain period of time. In reality, if there is no stream for a period of time, it will become a 404 status and disconnect the client connection.

TRANS_BY_GPT3

[winlinvip]

After introducing 404, the only downside is that the player may disconnect due to unpublishing or edge reconnection. Considering that the player itself cannot remain connected indefinitely, I personally think it is acceptable.

TRANS_BY_GPT3

[winlinvip]

Postpone to SRS4.

[SuperChrisliu]

Should support configuring read timeout.

Is there support for this configuration now? The streaming is disconnected, and ffmpeg keeps getting stuck while pulling the stream...

TRANS_BY_GPT3

[SuperChrisliu]

Should support configuring read timeout.

Is there support for this configuration now? The streaming is disconnected, and ffmpeg keeps hanging while pulling the stream.

ffmpeg supports the -rw_timeout parameter, which sets the timeout for IO operations in microseconds. It is important to note that when pulling multiple streams with ffmpeg, multiple rw_timeout parameters are required.

TRANS_BY_GPT3

[winlinvip]

Dup to #931

Attention should be paid to whether to disconnect or maintain the connection, as there are different demands in different scenarios, so it is best to make this configurable.

The issue of connecting to the origin with Edge is the same. Close this issue, please refer to #931 for details.

TRANS_BY_GPT3