srs
srs copied to clipboard
推流断开时,FLV断开播放,RTMP保持播放,行为不一致
我看目前的逻辑是等待客户端断开rtmp拉流链接。 httpflv的逻辑是srs server主动断开,这块是否可以做成一致?
![image](https://user-images.githubusercontent.com/93968/162662311-656d6178-e79f-452d-b95c-4d8fc006a8c2.png)
在flv拉流里有这个,但rtmp拉流没有
你好,rtmp2rtc视频播放花屏有遇到吗,可以交流下吗
我看目前的逻辑是等待客户端断开rtmp拉流链接。 httpflv的逻辑是srs server主动断开,这块是否可以做成一致?
![]()
在flv拉流里有这个,但rtmp拉流没有
#3021
This is a problem that should be consistent.
If there is no disconnection, the client will not be aware when the anchor starts streaming again, which provides a better user experience.
However, FLV is difficult to maintain because it requires deleting the HTTP mount.
Of course, sometimes RTMP also needs to be disconnected in order to save resources.
So I think the better solution is: when RTMP configuration is disconnected for streaming, whether to also disconnect the playback, the default is to not disconnect and keep it consistent with the current situation.
I have marked this issue as good first issue
, and everyone is welcome to provide a patch.
TRANS_BY_GPT3
This is a problem, it should be consistent.
If there is no disconnection, the client will not be aware when the anchor starts streaming again, which provides a better user experience.
However, FLV is difficult to maintain because it requires deleting the HTTP mount.
Of course, sometimes RTMP also needs to be disconnected in order to save resources.
So I think the better solution is: when RTMP configuration is disconnected for streaming, whether to also disconnect for playback, the default is to not disconnect and keep it consistent with the current setting.
I have marked this issue as
good first issue
, and everyone is welcome to provide patches.
Yes, I also expect that the streaming end can be disconnected while the HTTP end remains in a normal connected state, instead of EOF.
TRANS_BY_GPT3