Feature Bandwidth Calculator

[ingrid011]

Description
Based on the PRD of Bandwidth Calculator, that on the pricing page will be added that kind of calculator.
For the example, can be reference by this.
What I can think of is :

1. Need to create dynamic inputs so the user can play around. The dynamic inputs are : Total Streams, Duration, and Concurrent Viewers.
2. Then all of those informations will be processed to give result on : total bandwidth the user needs, and subscription plan suggestion for the user.

Question
I just confused where to start to break down the planning. Perhaps because I don't know how to do the calculation so I still don't have any thoughts about its complexity. Can anyone advice me on the calculation for this bandwidth calculator please?

(@tyohan @faiq-naufal @GagahGK @bonnis @owen-asumsi)

[ghaniswara]

I think first we need to figure out what are the variables that can affect the bandwidth size, afaik the following are the variables :

1. Video Resolution
2. Bitrate
3. Frame Rate
4. Video & Audio Codec
5. Number of Viewers

for the Video Codec specifically,I think there's two codec that is being used :

• from streamer client to server
• from server to viewers

For the WebRTC from here we can see that the codec that are being used are VP8 & H.264/AVC.
but for RTMP I think Broadcasting Client such as OBS support a more robust codec with the latest one is AV1 & H.265/HEVC which offer far more efficient coding than the previous mentioned codec, therefore less bitrate needed to deliver same video quality

We need to know what does the codec used in our service :
what codec are we supporting from client to our streaming server
what codec does the streaming server serve to the viewers

Then from all of that we can find the calculation of the bandwidth

I think the more accurate example of it is this calculator

[bonnis]

I think that the calculator example that @GagahGK gave is a good example. It is important to note that bitrate in itself is a product of two variables: the quality and the codec used. The quality here should encompass both framerate and the video resolution used. I think that showing bitrate or codec to our users may a bit too technical, we should give them the option to tweak them directly, but I think we should hide them behind the more familiar term "video quality". We could then infer the average bitrate by referencing data from the internet(example).

[ghaniswara]

IMO we should make bitrate as the user input not hiding them, while it's a little bit technical, that's something normal for streamer to deal with. also the service we're developing is for developer.

What we should do instead is to give a recommendation of minimal amount of bitrate is needed for certain video resolution & fps based on the codec. that's why we need to know what codecs are we supporting.

a 1080P 60FPS on H.265/HEVC will require almost half the size of bitrate needed for streaming.

A streaming site like twitch even offer a recommended setting to achieve resolution & fps target

We should offer them a flexibility to calculate the number since they wanted to know their usage as accurate as possible since this will affect their spending.

From my explanation above the user journey will be something like this :

First user will select :

1. Select protocol RTMP/WebRTC (this protocol will determine what are the codec supported by those protocol)
2. Select the Codec supported by us
3. Select the target resolution & quality

from the user selection above, we will suggest the recommended minimum bitrate to achieve the target (setting the bitrate too low can cause the stream to be interrupted)

then user can fill the remaining form / slider

• bitrate (should show note for the recommended bitrate / warning if the bitrate is too low)
• number of viewers
• duration
• etc

[bonnis]

IMO we should make bitrate as the user input not hiding them, while it's a little bit technical, that's something normal for streamer to deal with. also the service we're developing is for developer.

Yes, that's why we leave them the option to change the bitrate directly. I don't mean hide the term explicitly, but I just want to avoid the users to have to fill the bitrate themselves if they aren't too inclined to the technicalities.

First user will select :

1. Select protocol RTMP/WebRTC (this protocol will determine what are the codec supported by those protocol)
2. Select the Codec supported by us
3. Select the target resolution & quality

This is almost exactly as I imagined it to be. We currently only support WebRTC and the codec of the video that is distributed by the CDN will be determined by the ffmpeg command here. Meaning we only support x264 on the viewer side for now (if I'm not mistaken, CMIIW). So I think giving options on codec and protocol is not needed right now. Definitely a must after we implemented RTMP though. Then again, I only account for the viewer side, It's possible for other codecs to be used in the streamer-to-server connection. Should we add another separate section for the streamer-to-server connection? I think it's viable, but wouldn't it be slightly weird?

(should show note for the recommended bitrate / warning if the bitrate is too low)

I think this is an excellent suggestion. This will allow our clients to optimize more while being informed.

I also find another examples of this, where they separate the bitrate calculator and the bandwidth calculator.

• https://castr.io/bitrate-calculator/
• https://castr.io/bandwidth-calculator/