Hi,
I have recently been tasked to integrate OBS more with some of our solutions, first time looking at it in any depth, certainly got some wonderful features.
One element which is less than stella is the bandwidth test part of the auto configuration, not because it does not work, but it is impossible for a remote host to feed it data that it should be set to.
Let me outline the use case and a potential solution
- We have multiple users with differing levels of purchased service
- These users also have differing levels of bandwidth capability
- Using the auto configuration wizard is brilliant as no one really needs to know much else, however when they exceed either their plan or really their capabilities - test today, different tomorrow bandwidth environment - but the bandwidth test at the time said it was awesome - causes problems
So a request for a feature is this
As it appears OBS is RTMP based
- At the point of the bandwidth test
- Connect to the RTMP endpoint, make a function call, say getOBSConfig(), sending over all the current config, server, stream key, capabilities of the devices
- If the remote side sends back data, such as a flag to say 'use this' and then elements such as video bitrate, then use that rather than the bandwidth test
- If the remote side does not respond to the function call, just do the bandwidth test
- Continue with the auto configuration using which ever data set was available
An addition to this
- Perhaps also make the getOBSConfig() call each time the 'Start Streaming' is pushed, prior to calling publish, so again allow each time the bitrate to be altered, in case the user decides other settings are good (when they are not), or allowing the remote side to better control their network and capabilities.
This allows remote management of OBS as it is provisioned without getting in a tangle with users who have way over provisioned their capabilities and/or services that want to maintain a more stable publishing experience.
Shamrock
I have recently been tasked to integrate OBS more with some of our solutions, first time looking at it in any depth, certainly got some wonderful features.
One element which is less than stella is the bandwidth test part of the auto configuration, not because it does not work, but it is impossible for a remote host to feed it data that it should be set to.
Let me outline the use case and a potential solution
- We have multiple users with differing levels of purchased service
- These users also have differing levels of bandwidth capability
- Using the auto configuration wizard is brilliant as no one really needs to know much else, however when they exceed either their plan or really their capabilities - test today, different tomorrow bandwidth environment - but the bandwidth test at the time said it was awesome - causes problems
So a request for a feature is this
As it appears OBS is RTMP based
- At the point of the bandwidth test
- Connect to the RTMP endpoint, make a function call, say getOBSConfig(), sending over all the current config, server, stream key, capabilities of the devices
- If the remote side sends back data, such as a flag to say 'use this' and then elements such as video bitrate, then use that rather than the bandwidth test
- If the remote side does not respond to the function call, just do the bandwidth test
- Continue with the auto configuration using which ever data set was available
An addition to this
- Perhaps also make the getOBSConfig() call each time the 'Start Streaming' is pushed, prior to calling publish, so again allow each time the bitrate to be altered, in case the user decides other settings are good (when they are not), or allowing the remote side to better control their network and capabilities.
This allows remote management of OBS as it is provisioned without getting in a tangle with users who have way over provisioned their capabilities and/or services that want to maintain a more stable publishing experience.
Shamrock
