Need a way to determine whether the stream has stopped coming on a SRS RTMP server due to network disconnection on publisher's end. #3912
Replies: 2 comments
-
Good point, we also need that |
Beta Was this translation helpful? Give feedback.
-
Thank you for your feedback. As a streaming media server, SRS cannot determine whether the stream interruption is due to a temporary absence, a permanent departure, a poor network connection, or an intentional stop of streaming. These actions are not identified by any specific messages within the RTMP/WebRTC/SRT protocol layers. Generally speaking, a better approach is to identify these situations at the application layer. For example, by offering a live broadcast scheduling feature, if a broadcaster has scheduled a live session for one hour, then your system would naturally be aware that the allotted time has not yet elapsed, and it is possible that the broadcaster has only stepped away temporarily. For instance, you could provide additional options in your service's backend interface, aside from the 'End Stream' button, such as a 'Change Device' button. This would indicate that the broadcaster is not ending the live broadcast but needs to switch broadcasting equipment and restart the stream. Simply put, at the streaming media layer, SRS cannot determine the reason why a broadcaster terminates a live stream, whether they will continue streaming, or accurately inform users. Implementing these features at your business logic layer would be more appropriate.
|
Beta Was this translation helpful? Give feedback.
-
We have a specific need to utilize the SRS for streaming in conjunction with OBS or similar software. Presently, in the event of a publisher's connection drop during a stream, the default behavior of SRS involves buffering for end clients until the publish timeout occurs, ultimately terminating the stream.
Our objective is to implement a feature that displays a screen message such as "Publisher will rejoin shortly" upon a connection dropout. This aims to prevent end users from becoming frustrated and leaving the stream prematurely. Despite my investigation, I have not identified a straightforward method to achieve this.
Could someone kindly suggest a solution or provide guidance on how to implement this feature within the SRS framework?
Beta Was this translation helpful? Give feedback.
All reactions