When a streams starts with wi-fi and then I move away outside the range of wi-fi (or just disable wi-fi from iOS control center), wowza gocoder does not seem to try to re-connect using the cellular network so ‘onWZError’ callback on iOS is called without any recovery possibility. How can I gracefully reconnect behind the scene so users are not interrupted while streaming?
Hi,
The current GoCoder SDK release has some ABR capabilities that you can look into which may help in this case, where the device is going into a low-bandwidth scenario.
In the WZMediaConfig class of the GoCoder SDK:
The LowBandwidthScalingFactor property is the factor by which to scale the desired bitrate in low bandwidth conditions. Valid range is 0.0 to 1.0; any other value will be ignored. Setting a value of 0.0 indicates that the encoder should choose the best value; setting a value of 1.0 indicates that bitrate will never be throttled. The default is 0.75.
The FrameBufferSizeMultiplier property is the value by which to multiply the video frame rate to derive the number of video frames to buffer before the encoder starts to throttle bitrate and/or frame rate. For example: if the frame rate is 30 and the videoFrameBufferSizeMultiplier is 5, the encoder will buffer 150 (5 * 30) frames before throttling. Setting a value of 0 indicates that the encoder should choose the best value. The default value is 4.
The FrameRateLowBandwidthSkipCount property is the number of frames to skip when the encoder cannot keep up with the broadcaster. In low bandwidth conditions the encoder will skip frames to conserve bandwidth but still send consistent frames so the encoder can produce smooth playback. The maximum number of frames that can be skipped is equal to the key frame interval minus one - i.e. setting this to 29 with a key frame interval of 30 will produce a key frame only stream, setting to 1 will never skip frames. The default is 4 meaning skip 1 of every 4 frames.
Michelle
There is no graceful way to reconnect, from my experience. The low bandwidth callback only fires once per broadcast, so it’s not that useful because you would like to keep scaling down until you find the right bitrate.
I ended up creating my own server-side endpoint to test the bandwidth against before starting the broadcast. I set the bitrate and resolution based upon that. It works reasonably well but requires work on your end to setup.
