Blog

WebRTC Video Quality: Bitrate, Resolution, and Frame Rates – Part 1

Video is one of the biggest elements of communication these days. The success of a video call depends on the quality of the video. Real-time videos are a tough nut to crack. WebRTC does make things easier, but some elements still need more attention. 

Let’s talk about the factors that affect video quality and how to use them. These factors can be categorized as – Out of our control, Service-related, and Device-related.

1. Out of our control

Some instances are out of our control. We can only affect them a bit and up to a point. For instance, if the user has no Internet connection and no cellular reception, there’s nothing anyone will be able to do. We can only suggest they move someplace where their internet connection is better.

There are two aspects of video communication that are out of our control – 

1.1 Bandwidth

Bandwidth is the amount of data exchanged over the network. The higher the value, the better it is. We have little to no control over bandwidth issues:

• No access point

• Poor reception
• Faulty cable
• Too many users on the same access point
• Data flooding
• A firewall throttling traffic

None of this is controllable. At best, we can try positioning servers closer to the user.

With bandwidth, all we can do is estimate it to precision. WebRTC has mechanisms for bandwidth estimation. Knowing how much bandwidth is available allows us to make better use of the same.

That said, overestimated bandwidth sends more than the network can handle, causing congestion. Under-estimating bandwidth means sending less data than we could have. This will reduce the media quality we could have provided.

1.2 Transport protocol

TCP (Transmission Control Protocol) for WebRTC isn’t a good idea. The thing is, you don’t have control over what gets selected with the transport protocol.

This is how the distribution of the sessions looks like on TCP:

• Most calls won’t need TURN relay
• Calls needing TURN relay will use UDP
• The rest will use TCP
• There’ll be sessions that must have TLS
  

2. Service-related

Service-related issues are well within our control and are addressed by our infrastructure. How we decide architecture and deploy the backend creates all the differences.

2.1 Bitrate

Bandwidth isn’t something we can control, but bitrate can be. Bandwidth is the upper limit of data exchanged over the network. Bitrate is what the user is sending and receiving over the network. You must pick the bitrate for your application that serves your needs. Here are our recommendations – 

• Estimate the bandwidth with utmost accuracy
• The estimate is the largest bitrate you can send
• Use as much of that bitrate as possible (to the point of quality advantage)

It is important to remember that increasing bitrate doesn’t mean increased quality. Estimate bandwidth and decide your target bitrate to be lower or equal to the estimate.

2.2 Codecs

Codecs determine the media quality. G.711 is better than Opus for voice. Lyra and Satin are promising future alternatives. With video, there is VP8, VP9, H.264, HEVC, and AV1. Read our previous article on video codec here.

Some considerations when selecting a video codec for the WebRTC application – 

• VP8 and H.264 both are good and popular
• VP9 and HEVC offer better quality than VP8 and H.264
• AV1 delivers superior performance than other video codecs. It is new and not supported or understood by all yet
• H.264 has more hardware acceleration
• VP8 has temporal scalability
• You’d want to use simulcast or SVC for group sessions

Choosing a video codec isn’t a simple task. Experimenting with codecs is a time-waster. If you don’t know what you’re doing, RTCWeb.in is here to sort your video codec problems.

2.3 Latency

WebRTC infrastructure will affect the latency. The user location is not something we control but we do control servers locations. We can place the servers closer to the users to reduce the latency.

Here are some tips:

• Put TURN servers as close as possible to users.
• Have media servers for large group calls
• Users must connect directly if there is a single server for a meeting
• If there are different media servers for a single meeting, connect users to the closest one.
• The faster you take user data off the public network, the more control you get over the routing.
• The “shorter” the route from user to server, the better the quality.

Measure the latency of your sessions, reduce it for your users and repeat.

3. Device related

You don’t choose the device your users own. However, how your application is going to behave on these devices is in your hands.

3.1 Available CPU

Understand how much CPU is being used on the user’s device and how far you can go. When the device is out of CPU. The CPU will heat up in turn the device will heat up. Overuse of the CPU will shorten the battery life. It will lead to video freezes, rendering the video useless. The network will get congested due to frequent requests for I-frames

You have to check and make sure CPU use isn’t too high. If it is, reduce it. The best tool for reducing CPU use is reducing the bitrates.

3.2 Content-type

Content-type and placement matter in video communication. For instance, the bandwidth estimator gives a budget of 1,000 kbps. You assume that the CPU of both the sender and receiver(s) can handle that bitrate. How do you spend that budget?

First, you need to figure out the resolution you want to send. The higher the resolution the better the quality. The high frame rate provides smoother motion. WebRTC generally makes its own decisions based on the bitrate available. It will automatically increase or reduce resolution and frame rate to ensure the best quality.

WebRTC knows what resolution you captured your content with. It has no idea about the viewers’ screen or window resolution. It might send more data than needed, causing CPU and network losses.

WebRTC doesn’t know the importance of the content. This affects the decisions of how much to invest in bitrate. So, everything that needs to be done has to happen in your media server and its logic. You have to figure out and place/remove restrictions of what you want from your video.

3.3 Optimizing large group calls

Your code needs to be optimized to support large group calls. WebRTC provides a lot of powerful tools to scale a meeting. But, it also leaves a lot on you to figure. For that, RTCWeb.in is here with impeccable WebRTC development services.

RTCWeb.in is a seasoned WebRTC development company, having complete expertise in WebRTC technology. Contact us now to solve your video quality concerns.