DEV Community: Elecard

The Magic of Prediction in Video Codecs

Elecard — Thu, 08 Oct 2026 13:32:28 +0000

An easy-to-understand guide to prediction in video coding

When you watch a video in HD, you probably don't think about how much data would have to be transmitted if there were no compression. The numbers would be staggering. Yet the video reaches you quickly and in good quality — and for that, we have video codecs and one of their key tools, prediction, to thank.

Let's take a look at how it works.

Video Is Redundant — and That's Good News

Every video contains a huge amount of redundant information. Neighboring pixels within a frame are often very similar: the sky stays blue across many pixels, a wall keeps roughly the same color, and a person's face doesn't change dramatically from one pixel to the next.

But that's not all. Neighboring frames are often very similar, too. If a person is speaking on screen, the background behind them barely changes from one frame to the next. An arm moves smoothly rather than jumping randomly from one position to another.

Smart algorithms can take advantage of all this redundancy. And this is where prediction comes in.

Prediction is a process that tries to estimate what a block being encoded looks like before it is compressed. The estimate is based on data that has already been encoded, so the decoder on the other end can perform the same process and reconstruct the image.

There are two main types of prediction: intra prediction and inter prediction.

Intra Prediction: Extending the Picture

Imagine that you're encoding a small square block of an image. Some of the pixels to its left and above have already been encoded.

The idea behind intra prediction is simple: take these neighboring pixels and extend their patterns into the block being encoded at a particular angle — almost as if you were drawing the lines with a ruler.

The resulting prediction block is subtracted from the original block. If the prediction is accurate, the residual will be very small — and it is this residual that is then transformed and processed. The more accurate the prediction, the less data needs to be processed.

This tool appeared in the AVC standard, which offered seven angular prediction directions. In the next standard, HEVC, the number of angular directions increased to 33. In the latest standard, VVC, it doubled compared with HEVC. More prediction modes give the encoder more options for finding the best direction for a particular block.

Inter Prediction: Looking for the Block in the Past

Inter prediction works differently. The idea is to find the current block in frames that have already been encoded — previous frames or even future frames that have already been processed in coding order.

If a person in the frame has moved slightly to the right, the codec can find the corresponding content in a previous frame and essentially say: "This block is the same as that one, just shifted a certain number of pixels to the right."

This idea dates back to MPEG-1 and has been continuously refined ever since.

When Motion Gets Complicated: Affine Motion Compensation in VVC

A simple shift is just one type of motion. In real-world video, objects can rotate, scale, and become distorted. Classical codecs before VVC could describe only translational motion — as if a block simply slid from one position to another.

VVC introduced affine motion compensation. The block being encoded is divided into smaller 4×4-pixel sub-blocks, and each sub-block is assigned its own motion vector. This vector is not explicitly transmitted in the bitstream; instead, it is derived from a small set of parameters that are sent to the decoder.

As a result, the codec can model rotation, scaling, and translation more accurately — although with limitations: it still cannot handle very large rotation angles.

Why Action and Sports Videos Require More Bitrate Than Webinars

The reason is fairly straightforward. The simpler and more predictable the motion in a frame, the more accurately prediction can work, and the less residual data needs to be transmitted.

In a scene with a person speaking against a static background, inter prediction works extremely well: the background hardly changes, and there is very little motion. The codec can easily find the corresponding block in a reference frame, and a static background usually requires very little new information to be encoded.

A fireworks display or a fast-paced sports scene is a different story. Motion can be complex and widespread across the entire frame. Prediction is more likely to be inaccurate, residuals become larger, and more data needs to be transmitted.

That's why sports broadcasts typically require a higher bitrate than ordinary webinars at the same resolution.

Prediction is one of the key principles that allows video codecs to compress huge amounts of data while maintaining acceptable image quality. From simply finding a similar block in a neighboring frame to more sophisticated motion models in VVC, the goal remains the same: don't transmit the entire picture from scratch — transmit only what has actually changed.

The better a codec can identify and describe those changes, the more efficiently it can use every bit.

How We Tamed a “Finicky” SRT Feed

Elecard — Thu, 01 Oct 2026 12:35:51 +0000

In the world of professional broadcasting, stability isn’t just a metric—it’s everything. But what do you do when your incoming signal looks like a pothole-filled backroad, while your hardware requires a pristine high-speed autobahn?

That’s exactly what NorthTelecom (Dubai) ran into. NorthTelecom is a satellite communications and ICT service provider for the energy and maritime industries, media, telecom, enterprise customers, and humanitarian organizations worldwide.

The Challenge: When Modulators Meet Unstable Streams

NorthTelecom receives content from multiple providers over SRT. In practice, those incoming streams often arrived with errors or irregularities, and the company’s broadcast modulators simply couldn’t process them reliably.

The Solution: Elecard CodecWorks Gateway for Professional Restreaming

For this project, the team chose Elecard CodecWorks Gateway—a software product designed to switch live streaming protocols and adapt video streams for different network conditions and downstream equipment.

In simple terms, the Gateway became a buffer and translator at the handoff point:

SRT (input, where fluctuations can happen) → UDP (output, stable for modulators)

The solution was deployed to ingest more than 30 HD SRT streams from content providers. On the output side, the system generates clean HD UDP streams—and NorthTelecom’s modulators began operating without interruptions.

The Results: Stability, Efficiency, and Competitive Edge

The partnership yielded five key benefits for NorthTelecom:

1. Guaranteed Broadcast Stability

The Gateway ensured a continuous, reliable content flow in a format perfectly compatible with the hardware. This strengthened the entire broadcasting chain and improved service quality for end-users.

2. Fast implementation

CodecWorks Gateway’s support for standard interfaces and protocols made it easy to integrate into the existing workflow using a plug-and-play approach.

3. Smarter use of resources

CodecWorks Gateway helped the team meet deadlines while making the most of existing hardware. NorthTelecom was able to reallocate resources, reduce operating costs, and still maintain high performance.

4. Easy adaptation to project requirements

In complex projects, the ability to adjust quickly matters. NorthTelecom highlighted that the solution can be tailored to unique requirements and helps the team respond fast to non-standard scenarios.

5. Stronger market position

Stable streaming is as much a business decision as a technical one. By ensuring reliable SRT delivery, NorthTelecom met their clients' highest requirements, boosted service quality, and solidified their position as a top-tier provider.

The Client’s Perspective

"Working with Elecard was a seamless experience from start to finish. Their solution provided the precise technical capabilities we needed to ensure our video delivery was of the highest caliber. Beyond the software itself, we were deeply impressed by the Elecard team's responsiveness and technical expertise. They didn't just act as a vendor, but as a true partner invested in our project's success."

– Maurice Gascal, Sr. NOC Engineer, NorthTelecom

Your content deserves a smooth road.
Don't let protocol incompatibility or unstable signals hold your business back. At Elecard, we specialize in turning broadcast challenges into seamless workflows.

Ready to tame your streams? You know where to find us. ;)

Non-Intrusive SRT Monitoring — See Boro 3.0 in Action

Elecard — Thu, 24 Sep 2026 14:16:33 +0000

A major update to the Boro 3.0 monitoring system is coming soon, designed specifically for OTT and broadcast engineers.

What’s new in this version:

SRT sniffing — monitoring without an additional session
DVB and NDI support to cover more monitoring workflows
Advanced automation to detect and resolve issues faster

To give you a closer look at the new features, we’ve prepared a short video highlighting these and other key capabilities:

From Racks of Hardware to the Cloud: How TV Broadcasting Infrastructure Is Evolving

Elecard — Fri, 11 Sep 2026 11:39:09 +0000

Television broadcasting has come a long way — from racks packed with specialized hardware to software-based solutions that can run on general-purpose servers and in virtual environments.

In the past, a single TV channel could require several physical devices. Today, many of the functions of a broadcast headend can be implemented as part of a single software platform.

So, how did this transition happen, and why has the industry gradually moved away from specialized hardware? Let’s take a look at the key stages in the evolution of broadcast infrastructure.

When One Channel Took Several Devices

Digital broadcasting appeared in the West in 1996. It reached our market somewhat later, but by the end of the last century, the industry was already using professional digital satellite receivers.

Early digital headends looked very different from today’s software-based solutions. They were large, complex systems made up of numerous specialized devices. A single channel could require several pieces of equipment, meaning that one headend could take up several racks.

All of this equipment had to be connected with a large amount of cabling. Racks were filled with encoders, decoders, multiplexers, and other devices. Patch panels, matrices, bypasses — for broadcast engineers, all of this was simply part of the job.

Some devices did not even have a web interface. Basic settings could be configured from the front panel, while more advanced control required a separate management system.

This was the early stage of broadcast infrastructure: lots of specialized hardware, a fixed set of capabilities, and a fairly complex physical architecture.

Innovation: The Race for Efficiency

The next stage was driven by the development of specialized chips and digital signal processors.

At the time, broadcast equipment was not built around general-purpose x86 processors. Instead, manufacturers used discrete, specialized chips. They designed their own devices and boards, and users and integrators received complete, ready-to-use solutions that could be installed, configured, and then used for many years.

Manufacturers regularly introduced new developments and demonstrated improvements in encoding. The main criteria for progress remained largely the same: encoding quality, channel density per unit, MOS efficiency, and various preprocessing features designed to improve the visual quality of the picture.

Specialized signal-processing devices also emerged and helped simplify infrastructure for some operators. For example, when an operator could not afford a full range of encoders and decoders for every channel, such a device could limit the bitrate of individual channels without fully decoding the signal.

At the time, this was cutting-edge technology.

The Shift to x86 and Software

The next major step came with the availability of powerful general-purpose x86 processors.

At the same time, leading vendors began developing software for open server platforms. For operators accustomed to hardware-based solutions, this approach initially seemed unfamiliar. But the trend continued to gain momentum, and vendors gradually moved away from specialized hardware toward software-based solutions.

And this was not limited to encoders.

Other parts of the infrastructure were also becoming software-based, including transcoders, multiplexers, scramblers, and related functions. Developers began adapting these software products to run in virtual environments.

This changed the way broadcast infrastructure could be designed. Instead of relying on a collection of specialized devices, operators could implement different functions in software and run them on general-purpose servers.

From Individual Devices to Software Platforms

It was not just the technology itself that changed. The approach to broadcast products changed as well.

In the past, the capabilities of a device were largely determined by its hardware. Over time, manufacturers began developing additional features and offering them as separate options. A single encoder or decoder could include dozens of additional functions, each with its own price.

The development of software and cloud-based solutions made this model even more flexible.

A service could be offered not as a perpetual license, but as a rental. Pricing could, for example, be based on the number of hours of processing or the use of a particular service over a month.

For operators, this meant greater flexibility. They could make a deposit and then use it for the services they needed, depending on their current requirements.

What Made the Cloud Attractive to Operators?

Cloud-based models introduced another important advantage: simplicity.

Instead of maintaining the entire infrastructure themselves, operators can use the service they need and launch even a relatively complex task in just a few steps.

They also do not need to maintain the infrastructure themselves or keep additional shifts on hand for its operation. Technical support is provided directly by the service provider.

This combination of simplicity and flexibility is what makes the cloud approach so attractive.

At the same time, the cloud is not necessarily the only option for everyone. As the speaker noted, approaches to infrastructure can vary depending on the market and the specific situation.

Where Does CodecWorks Fit into This Evolution?

One example of the modern software-based approach is Elecard CodecWorks.

CodecWorks is a universal platform that combines multiple components and can be used to build a digital headend. Its microservice architecture makes it possible to configure the product according to a customer’s specific requirements and technical specifications, while optimizing the use of available resources.

Another advantage is its cross-platform approach. CodecWorks works with different hardware solutions and supports Linux and Windows operating systems, as well as a wide range of interfaces and codecs.

This approach illustrates just how far the industry has moved from the early days of broadcast headends, when a single channel could require several physical devices.

Today, much of the infrastructure can be implemented as software and adapted to a specific task.

What Comes Next?

The evolution of television broadcasting is not simply a shift from one type of hardware to another.

The industry first relied on numerous specialized devices. Then came specialized processors, more powerful general-purpose servers, and software-based solutions. The next stage brought virtual and cloud environments — and with them, new ways of licensing and consuming software.

And the evolution continues.

CodecWorks, for example, is currently being enhanced with statistical multiplexing and further improvements to its web interface. While many features are still in development, the product is already practically ready for DVB broadcasting.

The key trend behind this evolution seems to be greater flexibility: moving from fixed-function devices to software platforms that can be adapted to the specific needs of each operator.

AVC, HEVC, VVC: What’s the Difference and When Is It Time to Switch?

Elecard — Mon, 31 Aug 2026 14:06:11 +0000

A practical guide to video compression standards for the telecom industry

The abbreviations AVC, HEVC, and VVC come up constantly in technical discussions. But what do they actually mean in practice? Why can’t we simply choose one standard and stick with it forever? And when does it really make sense to consider switching to VVC?

Let’s break it down without getting lost in unnecessary theory.

Why Do We Need New Standards?

The reason is simple: hardware is becoming more powerful, video resolutions are increasing, frame rates are getting higher, and the number of bits per pixel is growing as well. All of this has to be transmitted and stored while keeping bitrates within reasonable limits.

Each new standard is developed with a clear goal: it should be at least 50% more efficient than its predecessor. At the same time, decoding should not be more than twice as complex, while encoding should not be more than ten times as complex.

Three Generations of Video Standards: What Has Changed?

AVC (H.264) is still the workhorse of the industry. It introduced a number of key tools that became fundamental to modern video compression, including angular intra prediction and Context-Adaptive Binary Arithmetic Coding (CABAC). Seven angular prediction modes and square transform blocks may look modest by today’s standards, but they represented a major step forward at the time.

HEVC (H.265) was the next generation and brought a significant improvement in compression efficiency. The number of angular prediction modes increased from 7 to 33. Tiles were introduced to enable parallel encoding of multiple image regions. The size of the basic processing block also increased.

VVC (H.266) is the latest standard, finalized in recent years. It was developed as a direct continuation of HEVC, with a clear goal: to significantly reduce bitrate once again while maintaining the same visual quality. The number of angular prediction modes doubled compared with HEVC. According to measurements, VVC is approximately 40% more efficient than HEVC in terms of PSNR.

What Does VVC Bring to the Table?

VVC inherits all the tools available in HEVC and adds a range of new ones.

More flexible block partitioning. HEVC used only a quadtree structure, which recursively divides a block into four parts. VVC adds binary and ternary partitioning, allowing a block to be split into two or three parts. This makes it possible to adapt more precisely to image content.

Affine motion compensation. Before VVC, motion prediction was limited to a single approach based on so-called translational motion. In reality, motion can be much more complex: blocks can rotate, zoom in or out, and undergo shear distortion. To support these more complex types of motion, VVC introduced affine motion compensation.

Matrix-based intra prediction. This is a fundamentally new type of intra prediction based on machine learning. Unlike the other tools in the standard, it does not have a strict mathematical foundation—it simply works well in practice.

Larger basic processing block. The size of the Coding Tree Unit (CTU), the basic processing block, was increased to 128×128 pixels. This reduces signaling overhead when working with high-resolution video.

Subpictures. A new data structure that makes it possible to encode multiple independent images within a single frame. This is particularly useful for 360° video, one of the key use cases considered during the development of VVC.

Screen content coding profile. VVC includes support for encoding content captured from a screen in its main profile.

Why Isn’t VVC Everywhere Yet?

If VVC is so much better, why isn’t it used everywhere? The short answer is: hardware support and computational complexity.

VVC encoding takes approximately 20 times longer than HEVC encoding. HEVC already requires significant computational resources—and VVC can require roughly 20 times more. This is a serious obstacle for real-time video encoding.

There are still very few hardware encoders and decoders that support VVC, with only a handful of models currently available on the market. The history of the industry also shows that early hardware implementations often support only a subset of a standard’s capabilities.

For example, when Intel released its first hardware HEVC encoder, it was technically an HEVC implementation, but in terms of the tools actually used, it was closer to AVC—with just seven angular prediction modes instead of 33. A more complete implementation came later in subsequent generations.

When Should You Switch to VVC? Practical Considerations

VVC can significantly improve compression efficiency compared with HEVC. Based on the estimates presented in the talk, the efficiency gain is around 40%, and under otherwise equal conditions, switching to VVC can substantially reduce bitrate.

However, compression efficiency is not the only factor to consider when choosing a new codec. Computational complexity and hardware support are equally important.

VVC is worth considering if:

compression efficiency and bitrate reduction are important to you;
you work with high-resolution video—in particular, 8K was one of the resolutions given special attention during VVC development;
you can afford the higher computational complexity of encoding, for example, in scenarios where encoding speed is not the primary constraint;
your users’ devices and software support VVC decoding.

You should be more cautious about switching if:

you need real-time encoding and have limited computational resources;
your audience uses devices without hardware or software support for VVC;
you require a complete hardware implementation of all the standard’s capabilities.

Ultimately, the right choice depends on the specific use case. VVC offers higher compression efficiency, but that comes at the cost of greater encoding complexity and still-limited hardware support. Before making the switch, it is therefore important to weigh the potential bitrate savings against the computational costs and the capabilities of the devices that will be used to decode the stream.

Professional video analysis tool in Action: A Video Tour of Our Latest Update

Elecard — Wed, 12 Aug 2026 13:20:00 +0000

Recently, we released an updated version of StreamEye Studio — a professional video stream analysis toolkit. This was a major release: we significantly improved performance, added new analysis capabilities, and redesigned the user interface.

Now we've prepared a video overview that demonstrates all the key improvements in version 2026.

What you'll see in the video:

How enhanced performance impacts workflow with large data volumes
What new analysis capabilities have been added in this version
How the interface has evolved and what benefits it brings to daily work

Whether you're a long-time power user of StreamEye Studio or are simply exploring the world of professional video analysis, this video is a practical guide to what's new and what's possible.

Watch the video below ⬇️

How to Distinguish Real Network Issues from Measurement Artifacts

Elecard — Thu, 16 Jul 2026 14:07:20 +0000

How do you ensure your monitoring measurements are relevant? In Elecard Boro, we've implemented a dual-verification architecture for MPEG-TS.

1. Path #1 (User Space): The packet stream from the network goes through libpcap to the main analyzer. It operates in user space and counts CC (Continuity Counter) errors.

2. Path #2 (Kernel Space): In parallel, at a lower level, data is intercepted via netfilter and sent to a second, independent analyzer that measures MLR (Media Loss Rate).

Why do we need this? If the readings from both "experts" align—great, we can be confident in the results. But if their graphs diverge—that's a powerful signal: "Attention, something's wrong with the measurement process!" This prevents us from jumping to conclusions about network issues.

Scenario 1: MLR and CC Errors Match

Errors appear synchronously on both graphs.

Likely cause: Actual network problems.

What to do:

Request a dump from the content provider.
Check for drops on switching equipment, deploy probes at the delivery network's input and output points to pinpoint where exactly packets are being lost.
Check CPU performance: RSS might not be enabled, causing one CPU core to be overloaded with data loss, or the entire system might be overloaded, preventing the probe from functioning correctly, or the receive buffer might be overflowing.

Accordingly, you can try increasing the incoming buffer, optimizing system performance, or reducing the load.

Scenario 2: CC Errors Present, but MLR is Normal

What to do:

Your operating system buffer may be overflowing or there may be insufficient performance. Try increasing them.
Check whether a broadcast source (e.g., ffmpeg) and the probe are running on the same machine. Process competition for CPU resources can cause such effects. The solution to this problem is to use RPS (Receive Packet Steering) to "pin" processes to different cores.

Scenario 3: MLR Errors Present, but CC Counter is Fine

What to do:

Check whether the probe is running in a virtual machine. We don't recommend using virtual machines for multicast monitoring because we cannot guarantee packets will be measured correctly. You can use them for OTT—measurements will be normal there.
Make sure the server isn't overloaded. If all CPU resources are consumed, the analyzer may simply not keep up with processing the stream, leading to false positives.

Conclusion

Reliable monitoring isn't just about having a good tool, but also a properly configured environment. The dual-verification approach built into the Elecard Boro monitoring system helps our clients quickly separate the real network problems from measurement artifacts.

How to Use Stream Analyzers for Digital TV Broadcasting: A Practical Guide

Elecard — Tue, 07 Jul 2026 12:49:44 +0000

Part 1: Solving GOP Structure and Compatibility Issues

Operating a digital television network isn't just about keeping channels on air—it's about maintaining quality that viewers expect and troubleshooting issues before they escalate. When something goes wrong in live broadcasting, every second counts. But how do you quickly pinpoint whether the problem lies in encoder settings, transport stream structure, or temporal metadata?

This is where specialized stream analysis tools become essential. In this series of articles, we'll walk through real-world scenarios that broadcast engineers face daily and show practical approaches to diagnosing and resolving them.

When File Analysis Becomes Critical

While live monitoring catches issues as they happen, file-based analysis is your diagnostic microscope. Here's the typical workflow: something breaks in production, engineers capture a few minutes of the problematic stream, and now they need to understand exactly what went wrong.

File analyzers serve three primary purposes:

Troubleshooting: Identifying the root cause of broadcast issues
Encoder optimization: Fine-tuning compression settings
Quality control: Validating compliance with standards and specifications

Let's explore how this works in practice with actual tools and techniques.

The GOP Structure Problem

Here's a scenario every broadcast engineer has encountered: legacy set-top boxes or older TV models suddenly can't play your stream. The audio works, video starts and stops, or you see freezing.

The culprit? Often, it's the GOP (Group of Pictures) structure.

H.264 has been around since 2003—over 20 years. Almost everything supports it, yet you'll still find legacy equipment that struggles with certain configurations. Specifically, the number of B-frames can make or break compatibility.

Why B-frames matter: They enable lower bitrates while maintaining quality by increasing encoding complexity through bidirectional prediction. But this comes at a cost—a more complex reference structure between frames.

The diagnostic process:

Open the problematic file in an analyzer
Check the GOP structure—not just length and whether it's closed, but the specific B-frame count
If you see three B-frames and have playback issues on older devices, try reducing to two, then one

You can visualize the entire reference structure: which frames reference which I- or P-frames, how bidirectional references work—everything needed to understand encoder behavior at a deep level.

Validating Standards Compliance

Beyond structure, you need to verify streams comply with H.264 specifications. A good analyzer will:

Decode the entire stream
Display frame-by-frame structure with thumbnails
Flag any standard violations in a dedicated error window
Show buffer overflow conditions

For example, if your stream shows buffer overflow errors, in our Elecard StreamEye analyzer you can:

See the exact frame offset where overflow occurred
Double-click the error to jump directly to that frame
Visualize the problem in bitrate graphs

Speaking of which—if your stream is supposed to be CBR (Constant Bitrate) at 8 Mbps but the graph shows wild fluctuations, you've immediately identified an encoder configuration issue.

The Bitrate Challenge

Standard bitrate calculation uses a one-second window. But you can recalculate using any window size. It can be useful if, for instance, you're planning to broadcast 4K content to an older fleet of set-top boxes with fixed hardware buffers. Before going live, you need to confirm these devices can handle your stream.

A file analyzer allows to:

Calculate bitrate
Compare against the device's documented capabilities
Identify potential decoder overflow before it becomes a viewer-facing problem

In our next article, we'll dive into transport stream structure and explore why timing metadata is where most "mysterious" broadcast issues actually hide—including the case of the 18-hour teletext desync.

How Network Controllers Impact Multicast Monitoring Accuracy

Elecard — Wed, 10 Jun 2026 10:36:41 +0000

Today we'll dive into what seems like a straightforward topic — multicast monitoring. Despite its apparent simplicity, there are plenty of complexities lurking beneath the surface. The first of these? Controller characteristics.

In multicast, we're primarily interested in two metrics. The first is packet loss, which matters for both IPTV and DVB. The second is jitter, which is especially critical for DVB and low-latency systems. What we're really interested in is the accuracy of measuring these two parameters.

Timestamps

To measure jitter, each packet needs a timestamp. This can be done in two ways:

Software timestamping — timestamps are assigned by the driver in the Linux kernel. The problem: under heavy load, the kernel can't process packets evenly, causing timestamps to drift.
Hardware timestamping — timestamps are assigned by the network card itself, regardless of system load.

We ran a comparison: under moderate load, the difference in peak jitter measurement is 10-15%. Doesn't sound too bad? But when measuring minimum jitter, the difference reaches tens of thousands of percent!

So whenever possible, always use hardware implementation.

RSS Queues: Distributing Load the Right Way

Picture this: one CPU core at 100%, the rest sitting idle. Sound familiar? This is the classic scenario when receiving multicast without RSS (Receive Side Scaling) configured.

Here's how it works:

By default, the controller generates interrupts that are handled by a single CPU core. A modern 2-4 GHz core can easily handle 2-5 Gbps of traffic. But when you add stream analysis (which is exactly what a probe does), a single core isn't enough. When a core is loaded at 100%, you get packet loss in the network card's buffer because the processor can't keep up.

The solution: use a card that supports multiple RSS queues and ensure interrupt balancing is enabled in the system. This will distribute the load across multiple cores. NB: you don't need to enable all available queues. Use only as many queues as needed to prevent any single core from hitting 100%.

If your card doesn't support hardware RSS queues, use the software implementation RPS (Receive Packet Steering) in Linux.

In dual-socket servers, each CPU has its own memory and PCIe bus. If the network card is connected to one CPU but processing happens on another, you get cross-CPU memory access. This slows things down and increases jitter. RSS queues let you pin traffic processing to the same CPU the network card is physically connected to. This significantly optimizes performance.

So the main recommendations are simple: use RSS queues and hardware timestamping.

How to Monitor Sports and eSports Streaming: Quality Strategies That Actually Work

Elecard — Wed, 03 Jun 2026 14:45:21 +0000

Sports streaming has zero tolerance for buffering. A frozen frame during a game-winning goal? Unacceptable. Lag during a critical eSports match? Your viewers are gone.

But here's the challenge: low-latency sports streaming is technically complex, and monitoring it requires a different approach than regular video delivery.

What This Webinar Covers

In this recording, industry experts from Elecard and Diantis System House share practical strategies for troubleshooting QoS and QoE issues in sports and eSports streaming environments.

You'll learn:

✅Key differences between sports and eSports broadcasting — and why they matter for your monitoring strategy

✅What "low latency" really means in practice — and the trade-offs you need to understand

✅UDP vs. SRT vs. RIST protocols compared — which one to choose for ultra-low latency scenarios

✅Hardware and latency requirements — what you actually need to deliver smooth viewing experiences

✅Real-world case studies — how companies solve quality issues across complex delivery chains (from source to transcoding, cloud platforms, and CDN)

This webinar is valuable for streaming engineers, broadcast technicians, OTT platform architects, and anyone responsible for delivering live sports or eSports content. Whether you're troubleshooting existing issues or designing a new low-latency workflow, you'll find actionable insights here.

Watch the full recording and discover how to keep your sports streams flawless — even under the most demanding conditions.

Troubleshooting Multicast Reception: 4 Common Pitfalls

Elecard — Wed, 27 May 2026 13:53:24 +0000

Most initial setup issues with multicast can be fixed in just a couple of minutes if you know where to look. Here are our top 4 common pitfalls when receiving multicast streams. This guide is based on our experience with Linux, as it's a go-to choice for high-performance networking.

Incorrect Data at Launch

We often get support tickets from users who, for example, have entered an IP address with five octets instead of four. It’s a surprisingly common mistake. Before you dive deep into diagnostics, take a moment to double-check your initial configuration: the multicast group address, the port, and the network interface. Getting these right from the start will save you a lot of headaches.

Firewall

On many Linux distributions, the firewall (iptables, firewalld, etc.) is enabled by default and blocks incoming traffic. A quick way to test this is to temporarily disable it. If the stream starts flowing, you've found your culprit. From there, it's just a matter of adding the right rules to allow the traffic permanently.

RP-Filter (Reverse Path Filter)

This filter protects against packets from addresses that aren't in the routing table. While useful, it can interfere with multicast reception. On modern distributions, the rules have become simpler, and it's often enough to simply disable it. If the stream starts flowing, you can either leave the filter disabled (if this is your internal, isolated network) or add the necessary routes for multicast reception.

Incorrect IGMP Version

Sometimes, your switch might not "understand" the requests coming from your server. This often happens because Linux defaults to IGMPv3, while many networks still operate on IGMPv2. Make sure you are using an IGMP version that is compatible with your network equipment to ensure smooth communication.

Following these steps should get your multicast stream flowing correctly. In our upcoming posts, we'll dive deeper into the common traps of monitoring multicast traffic and show you how to get reliable data, even under heavy load.

Stop Guessing: How to Measure Video Quality and Find the Best Encoding Settings

Elecard — Thu, 21 May 2026 11:24:22 +0000

Struggling to evaluate video quality objectively? Not sure which encoder settings will give you the best results? Choosing between multiple encoders but can't decide which performs better?

These are common challenges that video engineers and content creators face daily. This tutorial shows you practical solutions using Elecard Video Quality Estimator— a professional tool designed for objective video quality analysis.

Watch this short, practical guide to learn:
How to efficiently analyze video streams to determine their real quality.
How to interpret the results and metrics to choose the best encoding parameters.
How to compare different encoders to find the most effective one for your workflow.
How to avoid common mistakes that can lead to inaccurate conclusions.

Whether you're fine-tuning your encoding workflow, evaluating new codecs, or ensuring consistent quality across your video delivery pipeline, this tutorial provides practical guidance you can apply immediately.