DEV Community: Elecard

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:

How We Adopted Scrum in a Team of 20 Developers — and Went Through All Five Stages of Grief

Elecard — Wed, 01 Apr 2026 12:34:19 +0000

Hi there! My name is Olga, and I'm a Scrum Master at Elecard. I want to share the story of how we adopted Scrum — through pain, skepticism, and cakes at our retrospectives. If you're thinking about switching to an agile methodology or are already in the middle of it, our experience might be useful.

A Bit of Context

For those less familiar with the terminology, here's a quick rundown of the key concepts.

Scrum is a set of rules that helps a team build a flexible workflow. Development happens in short iterations (sprints), each iteration has a clear goal, and every team member has well-defined tasks.

Scrum Master is not a boss — think of it more as a facilitator. Someone who helps the team follow processes, removes obstacles, and runs meetings. Ideally, a Scrum Master shouldn't be a developer or a product manager — they shouldn't have a stake on either side.

Sprint is a short work cycle, typically three or four weeks long. Short enough to keep the team focused, long enough to deliver meaningful results.

Backlog is a prioritized list of tasks.

Story points are abstract units used to estimate the relative complexity of tasks.

Daily is a meeting that lasts no more than 15 minutes, held every working day. Developers discuss progress and flag any blockers.

Where It All Started

Our team consisted of 20 developers (including two tech leads) and one product manager. A big team with varied tech stacks and skill levels. And we had a whole pile of problems building up.

Communication Issues

We had one meeting per week. That was nowhere near enough. Managers often had no clear picture of who was working on what or how complex those tasks were. Cross-team communication was lacking too — some decisions could have been made at the component level instead of being escalated to the product level.

But the biggest pain point was developer distraction. Picture this: a developer — let's call him Alex — comes to work, grabs his coffee, opens a task, sits down to code, and immediately someone from marketing walks over: "Hey, we urgently need this!" Then someone from tech support. Then someone else. Alex could get interrupted 10 to 15 times a day. We'd essentially lose him for the entire day — he couldn't focus on a single task.

On top of that, we had no mechanism for surfacing problems. People just kept quiet about them. All of this meant there was no sense of team unity — and that directly affects the mindset you bring to work every day.

Organizational Issues

Back to Alex. Someone from another department gave him a task. But who's accountable for the result? The tech lead? The product manager? Alex himself? Nobody knew. There were no clear boundaries of responsibility.

With such a large team, it was hard for tech leads to track individual growth. And with just one meeting a week, we essentially had no processes or guidelines in place.

Strategic Issues

Deadlines were often set by guesswork and rarely met. The team had no understanding of how the product should evolve or what the market actually needed right now.

All of these problems kept piling up, and at some point it became clear: something had to change. Leadership and the team jointly decided to adopt Scrum. That's when I was offered the Scrum Master role — by that point, I was already certified.

The Five Stages of Accepting Scrum

1. Denial

At the start, it was completely unclear how Scrum could possibly help us. Or whether it could at all.

In textbook Scrum, a team is 7–10 people. We had 20, with different tech stacks and skill levels. No cross-functionality, so pulling tasks from a shared backlog in priority order simply wasn't feasible. Add a healthy dose of skepticism — we're all afraid of change. Nobody believed Scrum would actually work.

2. Anger

Many rituals triggered a negative response. We started with a task estimation scale of 1 to 10 — and immediately ran into trouble: the more complex the task, the harder it was to pin down a number. Is it a 7? An 8? Maybe a 9?

Meetings dragged on for half a day, sometimes the whole day. It was absolutely exhausting for the team. It wasn't easy for me either. I was used to working independently, and now I had to constantly engage with a large team, explain why each ritual existed, and answer the endless "Why do we need Dailies?" and "What's the point of estimating tasks?"

Dealing with other departments was a separate headache. I had to set boundaries and explain how to interact with our team under the new process.

3. Bargaining

This is where we started tailoring Scrum to fit our needs.

Team rules. For example, every sprint must include writing a portion of technical documentation and testing every feature.
Fibonacci numbers instead of a 1–10 scale. We switched to the sequence 1, 2, 3, 5, 8, 13, 21, 40. The bigger the task, the easier it is to tell the difference between adjacent values — making estimation much more intuitive.
Individual backlogs. Since the team isn't cross-functional, each developer got their own prioritized task list within the shared backlog.
Strict timeboxes. We set firm time limits for every meeting. If the team runs over, I gently but firmly wrap things up.

4. Depression

This is the stage where every Scrum Master asks themselves: "Did we make the right call adopting Scrum?"

I beat myself up for a long time over not doing it "by the book." The team was probably thinking: "Maybe we should just go back to the way things were?"

5. Acceptance

At some point, I had an important realization: you don't need to do it "the right way" — you need to do it the way that's right for your team.

By the end of the third sprint, we had a solid methodology in place. We'd settled into the new rhythm, agreed on how to interact with other departments, and the team started coming to meetings better prepared.

What Our Process Looks Like Now

Our sprints are three weeks long, and here's how they're structured:

Planning. All tasks are prioritized by the product manager — everything goes through them. If an urgent task comes in, it also goes through the PM: the developer picks it up and moves the lowest-priority item from their backlog to the next sprint.

Task estimation. We do this twice per sprint — at the beginning and at the end (a re-estimation pass). We use planning poker: everyone opens a free online tool, we discuss each task, and the team votes. If estimates differ by more than one step, I ask the people with the extreme scores to explain their reasoning, then we re-vote until we reach consensus or land on adjacent values and take the average.

Kanban board. Three columns: new tasks → in testing → ready for release.

Daily. Every day, 15–20 minutes. The team shares what they've done and flags any problems.

Demo. At the end of the sprint, the team presents what they've built — bugs fixed, features added.

Retrospective. My favorite ritual. I share how many story points the team closed during the sprint. The developer with the most points wins the Traveling Dragon Trophy 🐉.

We also have a great tradition of bringing something sweet to the retro — cake or pastries. When people are chewing, they filter less of what they say, and the feedback ends up being more honest. I once brought a cake to a retrospective, and the next time I didn't. In the "what went wrong" column, everyone wrote: "No cake." So now cake is a mandatory part of the process 😄.

Where We Ended Up

Here's what changed:

✅ Communication improved — both within the team and across teams. People started speaking up and sharing more.

✅ Clear boundaries of responsibility emerged. The product manager owns product development, the team owns implementation. Nobody goes directly to Alex anymore.

✅ Story points brought transparency. We can now see who's doing what and how complex their tasks are. This actually allowed us to revisit salaries for some team members.

✅ Planning became predictable. We have an average team velocity, which lets us plan product development ahead.

✅ The team sees the big picture. At the start of the year, the product manager presented the product road map — everyone now understands where we're headed and what our customers need.

✅ The atmosphere improved. The team even started their own daily tradition — at 4 PM, they all go do pull-ups together. A small thing, but it says a lot.

✅ Turnover dropped. The team became stable.

To back this up with data: I ran an anonymous survey within the team — not a single person said they wanted to go back to the old way. Nearly everyone noted that the product quality had improved.

The Key Takeaway

Don't be afraid to adapt the methodology to your reality. Textbook Scrum didn't work for us — and that's okay. What matters is embracing the core principles: transparency, regular feedback, consistent rituals — and then shaping everything else around your team.

Oh, and don't forget the cake at your retrospective. Trust me — it works.

How Video Compression Actually Works (Explained Simply)

Elecard — Wed, 25 Mar 2026 11:39:41 +0000

Ever wondered what happens to a video file when it shrinks from gigabytes to megabytes — without looking like a pixelated mess? The answer lies in video compression, and it's more elegant than you might think.

Whether you're a streaming enthusiast, a budding video engineer, or just someone curious about the technology behind every video you watch on your phone, understanding compression basics gives you a whole new appreciation for what's happening behind the scenes.

What you'll learn

In this short video, we break down the core principles of video compression step by step, using the widely adopted H.264/AVC codec as an example.

Here's what we cover:

Why compress at all? — The raw numbers behind uncompressed video might surprise you.
The YUV color model — How encoders see color differently than your eyes (and why that's a good thing).
How an encoder thinks — The logic behind turning raw frames into a compact bitstream.
Spatial (Intra) prediction — Finding redundancy within a single frame.
Temporal (Inter) prediction — The clever trick of only storing what changes between frames.
Frame types — I-frames, P-frames, B-frames: what they are and why they matter.
Discrete Cosine Transform (DCT) — The math that makes it all possible, explained without the headache.
Entropy coding — The final squeeze that removes every last bit of redundancy.

Why watch this

By the end of the video, you'll understand the full compression pipeline — from raw pixels to a compact bitstream. It's the kind of foundational knowledge that makes every other conversation about codecs, bitrates, and streaming quality click into place.

And if you want to go deeper, we've got you covered:

📖 Check out our free Video Compression Book for a more detailed dive.

🛠 Try Elecard StreamEye Studio to see compression in action — analyze frame structures, bitrate distribution, and more with your own video files.

Hit play and see what's really inside your video files:

When Video Looks Fine But Isn't: How Stream Analysis Saves Video Conferencing Quality

Elecard — Wed, 18 Mar 2026 08:55:28 +0000

How do you verify the quality of video conferencing services you deliver to your customers? If the honest answer is "we watch the stream and see if it looks okay" — you're not alone. But you're also flying blind.

Subjective assessment misses encoding errors, compression artifacts, and compliance issues that directly impact service quality — and, ultimately, your bottom line. One system integrator we work with decided to close that gap. Here's how they did it.

The challenge

Our client — a system integrator in East Europe specializing in end-to-end IT solutions, including video conferencing deployments — was delivering video conferencing services to their customers but had no reliable way to verify the quality of the video streams they were delivering. The team needed a proper analysis system. And they needed to build it from scratch.

What They Were Looking For

Their requirements were fairly straightforward but non-trivial to satisfy all at once:

Detailed analysis of video parameters — not just surface-level metrics, but deep insight into what's actually happening inside the stream.
Scalability — the ability to analyze a large number of streams, not just one at a time.
Broad format support — including resolutions up to 4K, because modern conferencing systems don't stop at 1080p.
Responsive technical support — waiting days for a reply isn't an option.

The Solution: Professional-Grade Stream Analysis

The client deployed Elecard StreamEye Studio — our suite of tools for professional video quality analysis and error detection in encoded streams.

StreamEye Studio is designed to help engineers optimize video compression, verify compliance with encoding standards, and catch problems that other tools simply miss. It provides clear, detailed visualization of stream data — the kind that turns guesswork into actionable insight.

For this particular client, two capabilities stood out:

1. Visual clarity — the ability to see exactly what's going on in a stream, presented in a way that's intuitive and easy to interpret.

2. Detection depth — catching issues that other analysis tools had overlooked entirely.

What Happened Next

Up and running in a day

StreamEye Studio was integrated into the client's workflow within a single business day. No lengthy onboarding, no complex infrastructure changes. The team was analyzing streams and serving customers almost immediately.

Catching what others missed

This is the part that made the biggest difference. During one of their projects, the client identified a data transmission visualization issue that other tools had completely failed to detect. StreamEye Studio didn't just flag the problem — it pointed to the root cause, allowing the team to resolve it quickly.

Building a quality control process from the ground up

With StreamEye Studio in place, the client built a robust, repeatable quality control process for their video conferencing services. What was once a gap in their workflow became a strength.

Stronger market position

Here's an underappreciated benefit of professional-grade analysis tools: they make you look good. When you can demonstrate to your customers that you have rigorous quality control backed by industry-standard tooling, it builds confidence. It signals expertise. And in a competitive market, that expertise translates directly into revenue.

The Takeaway

The client's feedback summed it up well: they accomplished everything they needed in a short time, building a complete video conferencing analysis system from scratch. Over time, they came to appreciate the full range of features and settings — describing the product as straightforward, intuitive, and accessible.

They also highlighted the responsiveness of our technical support team, noting that questions were answered quickly and thoroughly.

Why This Matters Beyond This One Case

If you're in the business of delivering video services — whether it's conferencing, streaming, broadcast, or anything in between — there's a broader lesson here:

Subjective quality assessment is not quality control.

Proper stream analysis tools give you:

- Objectivity — data-driven quality metrics.

- Depth — visibility into encoding-level issues that visual inspection can't catch.

- Accountability — documented proof of quality for your customers and stakeholders.

- Speed — faster root cause identification when something does go wrong.

Interested in how Elecard StreamEye Studio can fit into your video quality workflow? Learn more on our website or reach out to our team at sales@elecard.com — we're always happy to talk video.

Elecard Glossary: MPEG Family

Elecard — Fri, 13 Mar 2026 09:50:14 +0000

Ever felt lost in the alphabet soup of video formats? MPEG-1, MPEG-2, MPEG-4, MPEG-DASH… These abbreviations pop up everywhere in the telecom and streaming world, but what do they actually mean? And why are there so many of them?

In our next Elecard Glossary episode, we break down the MPEG family in a clear, beginner-friendly way.

We'll cover:

Why these standards were developed, where they are most commonly used today;
The fundamentals of MPEG-1, MPEG-2, MPEG-4, and MPEG-DASH — their purposes, differences, and how they relate to each other;
Adaptive streaming: What it is and why it's become essential for modern video delivery.

Whether you're new to the industry or just want to refresh your knowledge, this video will help you finally connect the dots between all those MPEG acronyms.

Hit play and level up your video tech vocabulary!

When The Network Fails, The Show Goes On: Meet ST 2022‑7 in Action

Elecard — Wed, 04 Mar 2026 13:02:45 +0000

Imagine: it's the live broadcast of the football game. Millions of viewers are glued to their screens. And suddenly — a signal path breaks somewhere between the stadium and the studio. What happens next?

If the broadcaster is using ST 2022-7 — most likely, nothing. Viewers won't even notice.

Let's take a closer look at how this works and why this technology has become the unspoken reliability standard in professional broadcasting.

What Is ST 2022-7?

IP networks are unreliable by their nature. They're prone to packet losses, jitter, and brief outages. For web browsing, that's tolerable. For live broadcasting, it's a disaster. The SMPTE ST 2022-7 specification solves this problem with an elegant and straightforward approach: Seamless Protection Switching.

Here's how it works:

The same media stream is transmitted simultaneously over two independent routes.
The receiving side gets packets from both streams and synchronizes them using RTP header fields defined in RFC 3550.
If one route degrades or goes down, data keeps flowing through the alternative path. No interruptions. No switching artifacts. No gaps.

Where Is This Used in Practice?

ST 2022-7 is found wherever signal loss isn't just inconvenient — it's costly.

📡 Live Broadcasting and Remote Production

This is where ST 2022-7 delivers its greatest practical value. Consider a live event — a concert, an awards ceremony, a breaking news broadcast. Cameras capture HD/UHD video and audio via SDI interfaces. The raw stream is encoded (AVC/HEVC for video, AAC for audio) and converted into IP streams.

To guard against disruptions — cable breaks, network overload — ST 2022-7 duplicates the RTP stream, encapsulates it in protocols like RIST or SRT, and sends it over two independent paths: for example, a primary fiber optic link and a backup satellite channel with a bidirectional back-channel.

Without ST 2022-7, a path failure could mean several seconds of lost signal. And losing even one second when millions are watching can entail significant financial and reputational costs.

🎙 Contribution Systems

Delivering signals from field sources — remote crews, on-location studios — to the central facility is a classic use case. Traffic passes through multiple provider networks, and the risk of degradation on any given segment is always present.

🖥 Studio-Based IP Fabrics

Modern studios are increasingly migrating to IP infrastructure built on ST 2110. Transmitting raw, uncompressed data requires a steady and stable input signal until the end of stream. Seamless redundancy here isn't a nice-to-have — it's a necessity.

Industry Recognition

ST 2022-7 isn't just a convenient tool. Major industry organizations consider it a fundamental element of robust IP infrastructure.

The European Broadcasting Union (EBU), in its Tech 3371 recommendation, specifies the use of ST 2022-7 seamless failover as a mandatory requirement for media nodes where signal continuity is critical. In particular, it's recommended as the minimum acceptable source redundancy requirement for SDI-over-IP systems defined in ST 2110.

With the ongoing growth of cloud services and remote production, demand for ST 2022-7 continues to rise. The more nodes traffic passes through, the higher the probability of failure on any given segment — and the more valuable a proven, deterministic redundancy mechanism becomes.

Pros and Cons: An Honest Look

✅ Pros

Reliability boost. Multi-path stream redundancy protects against packet losses and network disruptions.
Seamless switching. Automatic stream selection without noticeable interruptions in the production workflow.
Increased resilience in IP networks: suitable for high‑availability broadcasting.

⚠️ Limitations

Increased bandwidth demand. Duplicating streams means at least doubling the traffic.
Additional delay. The buffer size must be set to compensate the inter-stream delay between paths.

In practice, ST 2022-7 is used in combination with different transport protocols — UDP, SRT, RIST — and each pairing has its own nuances. The choice of protocol affects latency, loss resilience, and implementation complexity. This is a critical consideration for anyone designing real-world media delivery systems.

Want to Learn More?

This post only scratches the surface. In the full article, we dive deep into the specifics of using ST 2022-7 with different transport protocols, compare approaches, and share results of practical experiment: we ran a real-world test of seamless switching using ST 2022-7 + SRT and analysed stream behavior.

👉 Read the full article here

Elementary, Packetized, and Program Stream Explained: The Basics of Digital Video Streams

Elecard — Thu, 26 Feb 2026 09:09:30 +0000

Digital video comes with its own language — full of abbreviations that can feel overwhelming if you’re not working with them every day. ES, PES, PS… what do they actually mean, and how do they relate to each other?

In this first video of our Glossary series, we break down three fundamental concepts: Elementary Stream (ES), Packetized Elementary Stream (PES), and Program Stream (PS). This episode is a practical starting point for engineers, students, and anyone working with digital video who wants to better understand what’s happening inside a media stream — beyond the acronyms.

Why Digital Screens Are Becoming Essential in Modern Transport Stations

Elecard — Thu, 05 Feb 2026 14:34:13 +0000

Transport stations are no longer just places to change trains or catch a bus. Today, they are complex, fast-moving environments where thousands of people pass through every day. In such spaces, clarity, comfort, and timely information are not optional — they shape the entire passenger experience.

At first glance, it may seem that traditional schedules and arrival boards are enough. But in reality, a passenger’s journey is made up of many small moments: walking through corridors, waiting on platforms, navigating unfamiliar stations. And this is where digital screens begin to play a much more important role than it might seem.

Navigation without confusion

One of the key purposes of digital screens in transport environments is simple: help people find their way.

Clear directions, route maps, transfer information, and exit guidance significantly reduce stress — especially during peak hours. When information is updated automatically and in real time, passengers can quickly understand where to go and what to do next.

Interactive screens add another layer of convenience. Instead of asking staff or guessing, passengers can explore station layouts, plan transfers, and choose optimal routes on their own.

The right information at the right moment

Transport operations are dynamic by nature. Delays, platform changes, and unexpected incidents require instant communication.

Digital signage makes it possible to display content based on location, time, and context. Passengers see only what is relevant to them at that moment — not a stream of generic announcements. This targeted approach makes communication clearer, faster, and more effective.

One system instead of dozens of manual updates

Large transport hubs can have dozens or even hundreds of screens — on platforms, in halls, corridors, and vehicles. Managing all of them manually quickly becomes inefficient and error-prone.

Centralized digital signage platforms allow operators to manage all screens from a single system. Content can be scheduled, updated remotely, and adapted for different zones, transport types, or times of day. This simplifies operations and improves reliability.

Screens as an additional revenue channel

Beyond passenger information, digital screens also create opportunities for monetization. Advertising and informational campaigns can be targeted by route, location, or time of day.

When done correctly, advertising does not interfere with navigation or essential information. Instead, it becomes a natural part of the visual environment — useful for operators and unobtrusive for passengers.

Reliability when it matters most

In emergency situations, speed and consistency are critical. Digital signage systems allow operators to instantly activate predefined emergency playlists or messages across all screens.

This ensures that important information reaches passengers quickly and uniformly, even in high-pressure scenarios.

Final thoughts

Digital screens in transport stations are not about visual decoration. They are about navigation, safety, efficiency, and passenger confidence.

Platforms like Elecard ViCont are designed with these challenges in mind: centralized management, support for live video, schedules, web content, and advertising — all running reliably in environments with high passenger traffic.

As transport infrastructure continues to evolve, digital signage is becoming not an add-on, but a foundation.

How to Reduce Monitoring Costs Without Sacrificing Video Quality

Elecard — Fri, 30 Jan 2026 13:32:14 +0000

Monitoring video quality is essential for any operator — but it doesn’t have to be expensive. Hardware costs often make up a significant part of monitoring budgets, especially as the number of channels and streams grows.

The key lies not in monitoring less, but in monitoring smarter, so one can significantly reduce costs while keeping full control over service quality.

Let’s look at a practical approach to cost optimization using real monitoring scenarios.

Step 1. Monitor What Really Matters

In many real-world setups, teams are responsible for both encoding and content delivery. Trying to apply the same level of deep analysis everywhere quickly leads to unnecessary resource consumption.

A more efficient approach is to split responsibilities:

At the encoding headend
Focus on QoE (Quality of Experience) monitoring. This helps detect encoding-related issues early.
During content delivery
Shift the focus to QoS (Quality of Service) metrics. Here, the priority is stable signal transport.

This separation allows you to reduce the overall monitoring load without losing visibility into critical problem areas.

Step 2. Cut Hardware Costs with Lite QoE Mode

If you are using the Elecard Boro monitoring system, one of the most effective ways to reduce hardware requirements is enabling Lite QoE mode.

What is Lite QoE?

Lite QoE performs semantic analysis of the elementary stream (ES) without full video decoding. Instead of processing every frame in detail, the system analyzes stream structure and key parameters. Measurement accuracy is approximate, but sufficient to assess video decodability and detect key playback issues. This mode offers medium resource consumption, significantly lowering CPU load.

Why it matters

Medium resource consumption
Significantly lower CPU load
Allows monitoring of more channels on the same hardware

For many monitoring tasks, Lite QoE provides exactly the level of insight needed — without the cost of full decoding.

Practical Example: Frame Rate Monitoring with Fewer Resources

Let’s look at a real-life situation.

A video stream declares a 29.97 fps frame rate in its headers. However, during playback, the video stutters and doesn’t look smooth. Since the corresponding checks are disabled, the monitoring system doesn’t raise an alarm.

How can different monitoring modes handle this?

Full decode mode

The system decodes each frame to detect deeper-level irregularities. While this provides more detailed diagnostics, it’s much more resource-intensive, increasing CPU load and overall system cost.

Semantic frame header analysis

The system simply counts frame headers over time to estimate the actual frame rate. This method is lightweight, requires minimal CPU power, and is sufficient to confirm that playback irregularities exist.

It perfectly fits the goal of reducing hardware usage while maintaining essential control over video quality.

Thus, clear and flexible monitoring configuration options can significantly optimize operational costs.

The Result: Smarter Monitoring, Lower Costs

By choosing the right monitoring depth for each stage of the workflow and using flexible modes like Lite QoE, operators can:

Lower CPU load
Maintain essential video quality control
Detect real issues before they impact viewers

Clear and flexible monitoring configuration isn’t just a technical advantage — it’s a direct way to optimize operational costs while keeping services reliable.

Want to go further?

In a dedicated document, we’ve collected four more practical use cases showing how to solve real-world broadcasting challenges.