midday
New Member
Hello. I am Midday, and I develop RTMP-based live cloud services and broadcasting tools.
While developing both the cloud and broadcasting tools, I have come to question the reconnection attempt logic in OBS and would like to make a suggestion here.
When the broadcast in OBS terminates abnormally, it attempts to reconnect according to the reconnection settings.
I think this is a very useful feature in poor network conditions or various environments.
This functionality is indispensable, especially for continuous shooting scenarios like CCTV.
However, from the server's perspective, there are different opinions.
If the connection is interrupted due to network issues or server conditions, it is beneficial for the client to attempt reconnection.
But when a user's broadcast has an abnormally high bitrate or an excessively high resolution, the server will reject it.
Also, sometimes users mistakenly share a single stream key across two or more devices, attempting to broadcast simultaneously.
There are also bad actors who try to broadcast inappropriate content, and they need to be blocked.
In these cases, continuous reconnection attempts are merely abusive from the server's point of view. It only leads to a wasteful struggle for both the server and the client.
However, the most commonly used OBS just keeps trying to reconnect.
But what if OBS did not attempt to reconnect when receiving a specific event?
Instead of the usual NetStream.Publish.Failed,
if the server explicitly sends a NetStream.Publish.Denied or NetStream.Publish.BadName when it doesn't want to accept the stream,
wouldn't it make sense for the client not to attempt reconnection?
This way, we could eliminate the resource waste caused by the server repeatedly rejecting connections and the client continually trying to reconnect.
If a reason for the denial is sent with the Denied event and displayed in logs or a dialog box,
users could understand more clearly why their connection is failing.
I expect that if OBS makes this change first, many live streaming services will follow suit and make their own adjustments accordingly.
What do you all think?
While developing both the cloud and broadcasting tools, I have come to question the reconnection attempt logic in OBS and would like to make a suggestion here.
When the broadcast in OBS terminates abnormally, it attempts to reconnect according to the reconnection settings.
I think this is a very useful feature in poor network conditions or various environments.
This functionality is indispensable, especially for continuous shooting scenarios like CCTV.
However, from the server's perspective, there are different opinions.
If the connection is interrupted due to network issues or server conditions, it is beneficial for the client to attempt reconnection.
But when a user's broadcast has an abnormally high bitrate or an excessively high resolution, the server will reject it.
Also, sometimes users mistakenly share a single stream key across two or more devices, attempting to broadcast simultaneously.
There are also bad actors who try to broadcast inappropriate content, and they need to be blocked.
In these cases, continuous reconnection attempts are merely abusive from the server's point of view. It only leads to a wasteful struggle for both the server and the client.
However, the most commonly used OBS just keeps trying to reconnect.
But what if OBS did not attempt to reconnect when receiving a specific event?
Instead of the usual NetStream.Publish.Failed,
if the server explicitly sends a NetStream.Publish.Denied or NetStream.Publish.BadName when it doesn't want to accept the stream,
wouldn't it make sense for the client not to attempt reconnection?
This way, we could eliminate the resource waste caused by the server repeatedly rejecting connections and the client continually trying to reconnect.
If a reason for the denial is sent with the Denied event and displayed in logs or a dialog box,
users could understand more clearly why their connection is failing.
I expect that if OBS makes this change first, many live streaming services will follow suit and make their own adjustments accordingly.
What do you all think?