Closed winlinvip closed 2 years ago
The 'srt' data is received and pushed into a queue by the 'srt_server' thread. The 'srt2rtmp' coroutine retrieves data from the queue. The entire process involves one-way data flow.
When there is an error in the 'rtmp' interaction, only the 'rtmp' session can be closed. The error information cannot be passed to the 'srt_server' thread, and it is not possible to directly call the 'srt_server' interface to close the 'srt' session, which is not easy to handle.
There is a solution to consider implementing separate authentication using 'srt'. Of course, it is not possible to use 'st' to implement an HTTP client. Instead, the cpp-httplib library can be used. This library consists of only one '.h' file, and it may be feasible in terms of copyright.
TRANS_BY_GPT3
Discussed and decided to use global variables with locks to store the error. After replacing the IO with ST driver, we can use it without locking.
TRANS_BY_GPT3
Fixed in SRS 4.0
When SRT is streaming, it will be converted to RTMP and pushed to the backend. If the backend has authentication, it may cause the RTMP to fail. In this case, SRT will not disconnect but will keep retrying.
At this point, we have no idea what is happening. We only know that the SRT push is not failing, but the RTMP stream cannot be played. However, the SRT stream can be played.
At the same time, this is also a vulnerability, equivalent to ineffective authentication, because SRT can be played, it's just that RTMP cannot be played.
Therefore, when RTMP fails, SRT must also fail; or implement authentication and callback separately.
TRANS_BY_GPT3