DEV Community: Elecard

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.

How to Automate VoD Content QC: An Elecard Case Study

Elecard — Fri, 15 May 2026 18:22:27 +0000

Picture this: content volumes are growing, engineers are drowning in routine tasks, and the risk of broadcasting defective video keeps increasing. Sound familiar? This is exactly the challenge we faced when a major VoD service reached out to us.

The Problem: When Manual Work Becomes a Bottleneck

Initially, the client had a classic content preparation workflow:

Input storage — where master files from content providers and the internal studio landed
VoD transcoder — transcoded files into multiple profiles and saved them to intermediate storage
Packager — packaged the ready profiles for publication

Sounds logical, but there was a problem: the system operated in manual or semi-automatic mode. The transcoder ran in watch folder mode, and quality control was performed selectively and manually.

As volumes grew, this approach started failing:

Engineers spent too much time on routine operations
Checking every file manually became physically impossible
The risk of defective content going live was increasing: With more files, the chance of a video with a black screen, frozen frame, or missing audio slipping through to the audience grew. The potential damage to the brand's reputation was significant.

The Goal: Automate Everything End-to-End

The client set an ambitious goal — fully automate the media file preparation and verification process. The solution had to:

✅ Centralize management of all stages

✅ Automate quality control

✅ Verify files at every stage — from input to publication

To achieve this, they acquired a complete stack: an orchestrator, a VoD transcoder, and our system — Boro VoD. All components needed to be integrated with the orchestrator.

First, a quick look at Boro VoD.
Simply put, Boro VoD is your personal media file quality inspector. It’s a software solution that automatically analyzes video files based on rules you define.
The solution is built on a client-server model. Probes analyze media files from storage, checking the container, video and audio metadata. A Central Server with a Web UI and API manages the probes, assigns validation tasks, collects the results, and generates detailed reports (in PDF, CSV, or JSON).
The magic happens through verification templates — sets of tests for analyzing parameters and detecting errors. Tests fall into two categories:

Compliance Checks: Ensuring the container is MP4, the video codec is AVC, and the audio track is AAC.

Defect Detection: Finding frozen frames, black screens, sections of silence, checking container integrity, and verifying that video and audio durations match. Users simply select the necessary tests and set compliance conditions — the system does the rest.

Integration and the New Automated Workflow

For the first phase, the client decided to focus on the most critical pain point: validating files after transcoding. Our team successfully integrated Boro VoD with their orchestration system.

Here’s what the new, fully automated technical process looks like:

Step 1. The orchestrator detects a new master file in the storage. It immediately sends it for transcoding.

Step 2. As soon as the transcoder finishes creating the set of profiles, the orchestrator sends a command to our Boro VoD via API: "Validate these files using this template."

Step 3. Boro VoD accepts the task, and its probes begin the analysis. The orchestrator can check the task status at any time using its unique ID to see the progress percentage and a summary of errors found so far.

Step 4. Once the analysis is complete, Boro VoD generates a report. The orchestrator retrieves it and sees the final status: Passed, Warning, or Failed.

Step 5. Decision. From there, the logic is simple:

If the status is Passed, the file is good to go. The orchestrator passes it along for packaging and publication.
If the status is Failed, the file is rejected. It will not reach the viewer. A detailed error report is saved alongside the file, waiting for an engineer to review—freeing them to solve a specific, identified problem instead of performing manual checks.

The Outcome

Our client got exactly what they were looking for:

A fully automated workflow that runs 24/7 without human intervention.
100% coverage — every file is checked, not just a sample.
Engineers were freed up from monotonous work to focus on more complex and creative tasks.
The risk of publishing content with defects was reduced.
A scalable system ready to handle future growth in content volume.

This case is a perfect example of how smart quality control automation can transform potential chaos into a streamlined and reliable pipeline.

If you're facing similar challenges in your work, know that there is a solution. Learn more about the capabilities of Elecard Boro VoD on our product page.

Can You Combine a Transcoder, Packager, and DRM/CAS Scrambler All in One?

Elecard — Wed, 06 May 2026 12:38:45 +0000

In modern TV and OTT projects, the same technical challenges can be addressed in different ways: by distributing functions across multiple systems or by consolidating them into a single solution. In practice, the choice depends on network architecture, content protection requirements, and the diversity of end-user devices.

Let’s take a closer look at what a contemporary video delivery chain really consists of — from classic “old-school” DVB to OTT, DRM, and CAS.

From "Old-School" Multiplexer to Modern OTT

The multiplexer is a technology that's been around for over 30 years. It emerged in 1992 for DVB broadcasting and still works flawlessly today. It’s like an axe—a simple, reliable tool that does its job perfectly. The 188-byte transport stream structure, tables, transmission intervals—everything was designed so thoughtfully that the technology has outlived several generations of computers.

But the world has changed. With the growth of the internet came OTT platforms that deliver video over IP. And this is where things got interesting.

Packager: When You Need to "Slice" the Stream

Early OTT solutions were based on the same transport stream—it was simply sliced into chunks and transmitted over HTTP. Why? To solve several problems at once:

Adaptive bitrate — when bandwidth narrows, the player automatically switches to lower quality. In the worst case, at 128 Kbps, you'll see a frozen picture but still hear the commentators.

Support for different devices — some require high quality, others can only play SD content.

Over time, the industry shifted from transport stream to MP4 containers. Why? About 10% bitrate savings by eliminating redundant service tables needed only for DVB broadcasts.

Apple HLS and MPEG-DASH: Two Sides of the Same Coin

Apple HLS started with transport stream, then moved to MP4. The system is straightforward: there's a master manifest (playlist) describing available quality profiles, and media playlists with links to video segments.

MPEG DASH was designed for MP4 from the start and supports more capabilities.

It would seem that moving to MP4 opens new horizons: you can create long GOPs (up to 10 seconds instead of 0.5 seconds in DVB) and use pyramidal B-frame structures. However, real-world constraints often interfere: some devices do not support long GOPs, certain players fail with B-pyramid structures, buffer and codec profile limitations vary widely. As a result, engineers frequently have to balance optimal encoding theory with the practical limitations of client devices.

Content Protection: Multi-DRM as a Necessity

If you're a serious operator, you'll need to support three major DRM systems:

- Widevine (Google) — for Android devices and browsers

- FairPlay (Apple) — for iPhone, iPad, Apple TV

- PlayReady (Microsoft) — for Samsung, LG, and other Smart TVs

Each system requires its own encryption format. At minimum, you need 4 playlists, but in practice—often all 7, because some devices are finicky even with formats they're supposed to support according to specifications.

Technical Details That Complicate Life

Teletext — in DVB it's one technology, but in OTT you need to support five different formats (in DASH—two: TTML and WebVTT).
Ad markers — there are at least three standards (Amazon, SCTE-35, and others), and you need to support them all.
Subtitles — while ready-made subtitles are straightforward (TTML or WebVTT), recognizing DVB subtitles becomes a quest. Especially when dealing with Arabic or other complex languages.

CAS Systems and Scrambling Optimization

DVB broadcasting uses CAS systems with DVB-CSA1, 2, and 3 algorithms. This is where the Elecard team faced an interesting technical challenge.

The problem: block scrambling doesn't parallelize well—each subsequent block depends on the previous one. Even with AVX512 optimization, they only achieved a 20% speedup, getting 50 Mbps on a 4-core processor.

The solution was unexpected: instead of speeding up processing of one service, the developers began processing 8 services in parallel, loading them into a single 512-bit register. The result—a 7x speedup! Now the same 4-core processor handles 350 Mbps.

Conclusions

Modern video content delivery is a balance between technological capabilities and real-world limitations. A 30-year-old multiplexer coexists with modern OTT formats, while the desire to use advanced encoding features crashes against the quirks of client devices.

Can you "wrap everything at once"—transcoder, packager, and content protection? Technically—yes. But be prepared to support множество formats, standards, and versions of protection systems. This isn't just combining modules; it's a complex engineering challenge requiring deep understanding of the entire video delivery chain.

Multiplexing in MPEG Transport Stream: How It Works and Why It Matters

Elecard — Thu, 30 Apr 2026 09:52:04 +0000

The MPEG Transport Stream standard is nearly 30 years old, yet it remains the foundation of DVB broadcasting and IPTV—and is still frequently used in OTT workflows. Let’s take a closer look at why it exists, which parameters need to be monitored, and what typical TS workflows look like in practice.

What Is MPEG-TS and Why Is Multiplexing Needed?

When you watch a TV program, it may seem like only video is being transmitted over the network. In reality, it’s a combination of multiple data components:

- Video

- Audio (one or more tracks)

- Subtitles

- Teletext

- Service data for synchronization

- Ad insertion markers (SCTE-35), used by splicers for content replacement

All of this must be packaged in a way that ensures audio stays in sync with video, subtitles appear at the right time, and the receiver understands how the components relate to each other. This is exactly what the MPEG Transport Stream standard defines—a media container format that encapsulates all these elementary streams.

Multiplexing is a complex process that requires high precision and careful handling of multiple parameters. This is especially critical in real-time broadcasting, where the stream is processed and transmitted simultaneously.

Evaluating Quality: The ETSI TR 101 290 Standard

To assess how correctly a multiplexer is operating, the ETSI TR 101 290 standard defines a set of parameters to monitor and classifies errors by priority.

The most critical are Priority 1 errors. Two illustrative examples:

Continuity_count error — The continuity counter of TS packets is broken. This indicates that one or more packets were lost during transmission. On screen, this may appear as pixelation, image breakup, or visible artifacts.
PID error — An elementary stream declared in the PMT table is missing. For example, subtitles are listed in the PMT, but no corresponding data is actually transmitted. The receiver expects the stream, but it never arrives.

It’s important to understand that the real-world impact of these errors depends heavily on what happens to the stream next. DVB broadcasting via a modulator is the most demanding scenario. Segmenting into chunks for HLS delivery is far more tolerant.

DVB: The Most Demanding Scenario

If the output stream is sent to a DVB modulator, multiplexing requirements are extremely strict. Modulators are sensitive to:

PCR (Program Clock Reference) accuracy
PCR repetition intervals
CBR (Constant Bitrate) stability
IAT (Inter-Arrival Time) — packet spacing intervals
The presence and correctness of all service tables

Incorrect PCR placement may lead to synchronization issues at the receiver side. By contrast, if the stream is later segmented into HLS for OTT delivery, PCR precision is largely irrelevant. Therefore, multiplexing requirements vary significantly depending on the final use case.

Typical Multiplexer Workflows

Let’s look at several common scenarios.

Transcoding an SPTS

Probably the most common case. What happens:

An SPTS (e.g., UDP multicast) arrives at the input.
The stream is demultiplexed into its elementary components:

- Video

- Audio

- Teletext

- SCTE-35

Video and audio are transcoded (for example, MPEG-2 → AVC, MPEG → AAC). Teletext and SCTE-35 markers are passed through unchanged, or optionally removed from the output.
The streams are reassembled by the multiplexer.
The result is sent to the network, potentially using a different protocol such as RTP, SRT, or RIST.

SRT-to-UDP Restreaming with Remultiplexing

A common requirement is to receive a stream via SRT and redistribute it via UDP multicast. In theory, the stream could simply be forwarded unchanged. In practice, however, issues often arise:

PCR errors
Irregular packet timing
Analyzer warnings

Remultiplexing helps resolve these problems by:

Correcting PCR
Adding padding
Smoothing bitrate

This results in a cleaner, more standards-compliant stream before further distribution.

Splitting MPTS into SPTS (Demultiplexing)

The reverse scenario: the input is a multi-program transport stream (MPTS) containing several channels, and the output consists of separate single-program streams (SPTS), each carrying one channel.

For example, receiving one UDP multicast stream with 10 programs and redistributing them as 10 independent streams.

Statistical Multiplexing

This is a relatively new feature that has seen increasing demand in recent years.

Imagine you have 50 Mbps of bandwidth and 10 channels. If you divide the bandwidth evenly, each channel gets 5 Mbps (CBR). But this is inefficient: a news channel with mostly static content consumes the same bitrate as a fast-paced action channel.

Statistical multiplexing (statmux) solves this problem by dynamically redistributing bitrate among channels based on scene complexity. Each encoder evaluates the complexity of its current content and sends this information to a central analyzer. The analyzer collects data from all encoders and provides bitrate recommendations to each one, based on total available bandwidth and current demand.

The result: the same 10 channels within the same bandwidth, but with significantly improved overall quality.

Multiplexing is the foundation upon which everything else in television broadcasting is built. Once you understand it, it becomes much easier to move on to the next steps: scrambling, statistical multiplexing, and choosing the right hardware. We’ll cover those topics in the upcoming articles.

Digital Signage Under Full Control — Meet Elecard ViCont

Elecard — Wed, 22 Apr 2026 11:28:29 +0000

Digital screens are everywhere today: in shopping malls, offices, airports, and industrial facilities. Behind every bright display, however, there is a complex task — managing content centrally, updating it in real time, and ensuring reliable delivery.

Elecard ViCont is a digital signage system designed for centralized media management and real-time content delivery to screens of any scale. The platform enables businesses to create, schedule, and instantly update content, manage distributed screen networks from a single interface, and monitor playback quality.

In this introductory video, we briefly explain:

how the system works,
what business challenges it solves,
and the key benefits it brings to operators, retailers, and enterprise customers.

If you are interested in video delivery technologies, telecom infrastructure, and modern digital advertising solutions, this video is a great starting point to discover Elecard ViCont.

Observe Without Interfering: How Non-Intrusive SRT Monitoring Works

Elecard — Mon, 20 Apr 2026 08:17:03 +0000

In the world of professional streaming and telecom, quality monitoring is always a trade-off. We want total visibility into our streams, but we don't want the monitoring process itself to interfere with content delivery.

Traditional monitoring often relies on Relays or Proxies. While convenient, these methods have a significant downside: they create extra links in the chain, add latency, and double the load on the source.

Today we’re diving into a more elegant approach: non-intrusive monitoring. Let’s explore how to "observe" a session without breaking it or bloating your traffic.

What is Non-Intrusive Monitoring?

In short, it’s the ability to monitor an existing session between a source and a receiver from the sidelines. The probe (monitoring software) doesn't establish a separate connection and doesn't act as an active intermediary like a proxy.

✅ Why It’s a Game Changer

Targeted monitoring. The probe watches only the session you need — nothing extra.
No traffic duplication. No second session is created, so the load on the source doesn't increase.
No relay/proxy. No additional latency, no extra points of failure.

⚠️ Limitations

Expertise required. Configuring the probe and network equipment calls for a network engineer's skills.
Slight data discrepancy. Probe readings may differ slightly from metrics on the receiver side. Still, this is more accurate than creating a separate monitoring session.
Setup isn't always straightforward. Configuring monitoring tasks requires attention.
Encryption adds complexity. Monitoring encrypted streams may be limited or impossible.

That said, in most practical scenarios, the advantages clearly outweigh the limitations.

Three Ways to Access Data

Non-intrusive monitoring can be implemented in several ways depending on your infrastructure. The core principle stays the same: no separate session is created, and already-established sessions are not interrupted.

1. Network TAP

A Network TAP (Test Access Point) is a hardware device physically inserted into a network cable to passively copy all traffic in both directions.

It provides a faithful copy of the traffic, unlike SPAN ports, which may drop packets. Key limitation: additional hardware is required, physically splitting the network. This introduces a new point of failure — a factor that can't be ignored when designing fault-tolerant infrastructure.

2. Port Mirroring (SPAN)

SPAN (Switched Port Analyzer) is a feature built into virtually all modern switches. It copies packets from one or more ports to a designated destination port, where the monitoring device is connected.

The main advantage: no additional hardware needed — the switch is usually already in the network.

However, SPAN has a potential issue — packet loss on the mirrored port. This can happen for two reasons:

The mirrored port has lower priority than others and drops packets first under heavy load.
The combined volume of mirrored traffic may exceed the bandwidth of the destination port.

For most monitoring tasks, SPAN offers the best balance between ease of deployment and functionality.

3. Installing Directly on the Source or Receiver

If the source or receiver is software running on an x86-compatible machine with Windows or Linux, the probe can be installed right there.

In this configuration, the computer's own network subsystem effectively acts as a Network TAP — no additional hardware needed. This is the simplest path when the infrastructure allows it.

Conclusions

Non-intrusive monitoring of the SRT protocol is a highly effective solution that addresses a long-standing industry need. Despite certain limitations and greater configuration complexity compared to standard method, its advantages outweigh the drawbacks.

One additional important factor should be emphasized: the cost of non-intrusive monitoring is practically identical to that of conventional approach, since it does not require increased probe hardware performance.

If you'd like to learn more about specific use cases or technical details, explore the full article.

Is Your HDR Really Correct? Find Out

Elecard — Wed, 08 Apr 2026 12:56:12 +0000

HDR is becoming the industry standard — but are you confident your streams contain correct HDR metadata?

In this episode, we demonstrate how to:

verify the presence of HDR in a video stream;
identify the HDR format in use;
analyze and validate HDR metadata using Elecard Stream Analyzer and Elecard StreamEye.

Elecard tools support HLG, HDR10, HDR10+, Dolby Vision, and Vivid across modern video formats — AVC, HEVC, VP9, and AV1. With Elecard Stream Analyzer and Elecard StreamEye, you gain full visibility into HDR streams.

This video will be especially valuable for video engineers, QA specialists, and developers. If you work with HDR content, this practical guide will help you reduce troubleshooting time and improve delivery reliability.

Watch here: