Well actually there are a few approaches.
Naive soultion
A rough yet Simply calculate the size of a frame and multiply it by the framerate(Real one, not nominated) and after that add the kbps of the sound. You should get quite accurate picture of actual bandwidth.
For frame rate calculation read about Dynamic frame rate controls
OpenTok approach (The legit one)
I bet that a good User experience solution would be not to show that everything's bad, but to adjust the stream quality, indicating errors only in case of a total faiure(Like Skype does). Look at this:
Starting with our 2.7.0 mobile SDK release, you can start a publisher
with per-determined video resolution and frames per seconds (fps).
Before using the API, you should be aware of the following:
- Though HD video sounds like a good idea at first, from a practical
standpoint you may run into issues with device CPU load on low to
medium range devices. You may also be limited by the user’s
available bandwidth. Lastly, data charges for your users could run
high.
- Available on the device. The actual empirical values for these parameters will vary based on the specific device. Your selection
can be seen as a maximum for the resolution and frame rate you are
willing to publish.
Automatically adjusted based on various parameters like a user’s packet loss, CPU utilization, and network bandwidth/bit-rate. Rather
than attempting to do this dynamically on your own, we recommend
picking meaningful values and allowing OpenTok to handle the fine
tuning.
Bandwidth, set your publisher video type property to “screen” instead of the default “camera” value.
Taken from here
So, here's what you should do:
Implement <OTSubscriberKitNetworkStatsDelegate> protocol first. It has a method called
- (void)subscriber:(OTSubscriberKit *)subscriber videoNetworkStatsUpdated:(OTSubscriberKitVideoNetworkStats *)stats
Which as you can see has a OTSubscriberKitVideoNetworkStats object passed to it.
Next, you can extract three properties from this object:
@property (readonly) uint64_t videoPacketsLost - The estimated number of video packets lost by this subscriber.@property (readonly) uint64_t videoPacketsReceived - The number of video packets received by this subscriber.@property (readonly) uint64_t videoBytesReceived – The number of video bytes received by this subscriber.@property (readonly) double timestamp – The timestamp, in milliseconds since the Unix epoch, for when these stats were gathered.
So, feel free to play around with these values and implement the best solution for your app.
Moreover, they have published an article specially adressed towards managing different bandwidth on conference calls. Check it out.
UPD:
While I was writing the answer @JaideepShah mentioned an amazing example. Read throughly the explanation for this example. There is a table indicating proper resolution for right values I mentioned above.
