It denotes the number of video frames that are either sent or received per second.

We usually refer to FPS also as frame rate.

The post FPS (Frames Per Second) appeared first on BlogGeek.me.

DTX is an extension to the Opus voice codec and can be enabled via SDP negotiation.

With DTX enabled, if there’s silence or just background noise that is being encoded by Opus, it will be replaced with a single frame every 200 milliseconds (in Opus) instead of the default of a frame for every 20 milliseconds.

DTX is a useful tool for large group calls where the SFU needs to route many audio channels to the viewers. Since usually one or two people will be speaking at a time, any other participants whose microphone isn’t muted can be switched to DTX mode, saving on bandwidth and packets.

The post DTX (Discontinuous Transmission) appeared first on BlogGeek.me.

It is a term often used with video encoders, to indicate that the encoder works in a constant bit rate, generating the same number of bits per a short period of time (usually 1 second or less).

CBR encoding schemes work well when the network bandwidth is known and limited and is quite common in live video sessions where latency must remain low.

The compression created by CBR encoding schemes are great for sending media live over a network, but not as good when needing to store recordings as they tend to be larger than necessary.

WebRTC uses CBR by default when encoding camera sources.

The other popular encoding scheme is VBR.

Why is CBR Important?

In the world of WebRTC, maintaining a steady stream of data is crucial. WebRTC is all about real-time communication, which means there’s little room for buffering or lag. WebRTC needs to first understand how much bandwidth is available on the network, by way of bandwidth estimation. Once an estimate is made, it tries to never overshoot the available bandwidth and it does that by employing CBR encoding over the outgoing video channels.

By using CBR, you’re ensuring that the data flow remains constant, which can lead to smoother playback and fewer interruptions. This is especially beneficial in cases where the available bandwidth is low or fluctuating and trying to send more than the network can handle may lead to packet losses, latency and degradation in video quality.

However, it’s worth noting that while CBR can offer stability, it doesn’t always guarantee the best quality. Since the bitrate remains constant, even simpler parts of a video or audio stream that don’t require as much data will still use the same amount. This can sometimes lead to inefficient use of bandwidth.

CBR vs Other Encoding Methods

As mentioned earlier, the main alternative to CBR is VBR or Variable Bitrate. VBR adjusts the bitrate based on the complexity of the media being encoded.

For instance, a quiet audio segment or a static video scene might use a lower bitrate, while a complex action scene or a segment with multiple instruments playing might use a higher one. This dynamic adjustment can lead to better overall quality and more efficient bandwidth usage.

However, it might also result in unpredictable bandwidth spikes, which can be problematic for real-time communication.

Constant Bitrate Advantages

CBR’s strength lies in its predictability. For applications and platforms built on WebRTC, where real-time communication is the core focus, CBR can offer a level of stability that’s hard to beat.

For the most part, if you are using cameras, you will be using CBR in your WebRTC implementation.

The post CBR (Constant Bit Rate) appeared first on BlogGeek.me.

It is a widely used compression format (=video codec) that is used extensively in the industry. This includes video conferencing systems, TV broadcasting, webcams, smartphones, etc.

It is royalty bearing and is governed by the MPEG-LA.

WebRTC and the H.264 codec

It is one of the mandatory to implement video codecs in WebRTC, and it is available in all browsers supporting WebRTC. On some Android devices, where a hardware implementation of H.264 isn’t accessible, there is no support for H.264.

A royalty free implementation known as openH264 has been introduced by Cisco and has been integrated into browser implementations.

The post H.264 appeared first on BlogGeek.me.

It is a term often used with video encoders, to indicate that the encoder works in a variable bit rate, generating different amount of bits per second based mainly on the content. The end result over a long period will be on average the bitrate we are aiming for, but there are no guarantees that short periods of time will adhere to that bitrate.

VBR encoding schemes aren’t popular with real time media since they don’t adhere to bandwidth constrains and may cause congestion and latency. VBR is more popular with recording and streaming of pre-recorded content where latency isn’t as hard a requirement as in live streaming.

The other popular encoding scheme is CBR.

The post VBR (Variable Bit Rate) appeared first on BlogGeek.me.

AV1 is a new video codec developed and specified by the Alliance for Open Media.

As a codec, it is targeted to be the successor of VP9 and H.265, offering better performance.

The most important aspect of AV1 is it being a royalty free codec.

The post AV1 appeared first on BlogGeek.me.

The alliance was formed in 2015 with a goal to bring high quality video codec with a large ecosystem and market acceptance.

Members of the alliance include Google, Microsoft and Mozilla (all browser vendors) among others. The alliance started with 7 vendors and now includes over 20.

The video codec being specified by AOMedia is known as AV1.

The post AOMedia appeared first on BlogGeek.me.

For voice, the MTI codecs are G.711 and Opus.

For video, the MTI codecs are H.264 and VP8 (web browsers and devices must implement them both, while applications and services can decide which ones to use).

Web browsers are actively adding VP9 support as well, even though it is an optional video codec in WebRTC.

The post MTI (Mandatory To Implement) appeared first on BlogGeek.me.

H.265 is a new compression specification that is making its way into the industry as the successor of H.264. This makes it a candidate for a future video codec in WebRTC.

Like H.264, H.265 is royalty bearing and is governed by the MPEG-LA, although exact patent holders and costs are yet to be organized.

H.265 is assumed to be more CPU intensive than H.264 with better compression results. Its main “competitor” in WebRTC is VP9.

Technical Advancements

From a technical standpoint, H.265 offers significant improvements over H.264. It utilizes advanced algorithms and coding techniques to achieve up to 50% bitrate reduction while maintaining the same video quality. This is achieved through features like Coding Tree Units (CTUs), which allow for more flexible partitioning of the video frame, and improved motion compensation algorithms. The codec also supports resolutions up to 8K, making it future-proof for emerging high-definition formats.

WebRTC and H.265

In the context of WebRTC, adopting H.265 means focusing on Apple devices (Mac, iPhone and iPad via Safari browsers). It is worth noting that H.265 is not yet universally supported in WebRTC implementations due to licensing complexities and hardware constraints.

Licensing and Adoption

One of the major hurdles for the widespread adoption of H.265 is the licensing model. Unlike its predecessor, H.265 has multiple patent pools, making it more expensive to implement. This has led to slower adoption rates, especially among open-source projects and smaller enterprises.

The post H.265 (HEVC) appeared first on BlogGeek.me.

A typical video call will strive to work at 30 frames per second (fps), and that number will drop depending on the processing capabilities of the endpoints, bandwidth available and network conditions.

The actual frame rate of a video session fluctuates a bit through time, usually due to packet loss.

The post Frame rate appeared first on BlogGeek.me.