In the world of professional video transport, you’d be forgiven for assuming that if you send a compliant stream, any professional decoder should be able to play it back reliably. After all, standards are standards… right?
Unfortunately, that’s not how it plays out in the real world.
The truth is, video encoder and decoder interoperability remains one of the most frustrating and time consuming challenges in live video workflows, especially in IP based, protocol native distribution. Even when everything looks good on paper, the result on screen can be anything from smooth playback to stuttering video and missing audio.
So why does this happen? And more importantly, what can we do about it?
Why Interoperability Matters in Live Contribution and Distribution?
In live broadcast operations, there are countless situations where mixing equipment from different vendors isn’t just helpful, it’s essential.
Consider a major sporting event, where rights are delivered to dozens of different takers, each with their own master control environment. Or breaking news, where feeds must be turned around instantly to broadcasters worldwide. There is no time and often no ability to ship and set up vendor specific hardware in advance. In these moments, the ability to mix contribution and distribution equipment from different vendors ensures the content can get through, reliably and fast.
But the benefits of interoperability go far beyond the headline moments.
It allows broadcasters to maximise existing infrastructure, using the equipment they already own rather than replacing it just to meet a specific vendor’s ecosystem. It also helps giving organisations the freedom to evolve their tech stack over time without rebuilding the entire pipeline.
In an increasingly global industry, geopolitical and regulatory realities also come into play. Some regions are restricted from using certain vendors due to sanctions or trade rules. Standardised, interoperable workflows make participation possible without excluding entire geographies or organisations.
Freelancers and smaller production crews, especially in remote or under-resourced areas, often operate with whatever gear they have. If we want inclusive, scalable contribution, interoperability is the bridge that connects them to the wider network.
And when it comes to major global events like sport, news elections etc, scaling up rapidly and efficiently is key. Being able to mix and match compliant gear lowers costs, reduces setup time, and simplifies support across hundreds of feeds.
Ultimately, by embracing interoperability, broadcasters and service providers can reduce the need for dedicated, shipped equipment, cut carbon impact, support sustainability goals, and offer greater flexibility to contributors and takers alike.
Not All Standards Are Truly Standard
While many vendors claim compliance with standards like H.264, H.265, MPEG-TS, and SRT, what “compliance” means in practice can vary wildly. These standards are often broad and leave room for interpretation, especially around areas like timing, packetisation, bitrate control, and stream multiplexing.
For example, two encoders might both claim to be MPEG-TS compliant, but one might insert PAT/PMT tables more frequently, or mux PCR values differently, affecting how the stream is parsed downstream. Similarly, audio streams may use different channel layouts, codec profiles, or PID mappings, even under the same ‘standard’.
Metadata handling (e.g. SCTE-35 insertion or closed caption embedding) is another common point of divergence. Some decoders will pass over missing or malformed metadata gracefully while others will fail completely or behave unpredictably.
The same is true for ARQ protocols like SRT or RIST. while the protocol ensures packet delivery and integrity, it doesn’t standardise how streams are muxed or timestamped before they’re wrapped. That’s where problems often begin, not in the network, but in the assumptions made by encoder and decoder implementations.
Encoders and Decoders Are Built for Specific Assumptions
No encoder is designed to work perfectly with every decoder. Each vendor builds their products with certain assumptions, about network behaviour, decoder buffer models, timestamp alignment, and how muxing should be handled under load.
One encoder might expect the decoder to tolerate minor PCR drift while another might assume strict compliance with PCR/PTS/DTS relationships such as in professional IRDs. Some decoders expect perfectly constant GOP structures; others can handle variability. Even small differences in PAT/PMT frequency, or audio frame spacing, can cause dropouts or playback errors, especially in professional IRDs or tightly specified receiver workflows.
Bitrate control models also vary, encoders with aggressive VBR might cause decoding instability on devices tuned for CBR or capped VBR. And in low-latency scenarios, some encoders prioritise quick delivery at the cost of GOP consistency, which certain decoders aren’t built to handle without prebuffering.
These issues often don’t surface in lab conditions. It’s only when you’re live under real network loads, with actual decoder hardware in the field, that incompatibilities emerge. And by then, it’s usually too late to change the encoder or reconfigure the decoder without disrupting the broadcast.
Transport Is Not the Problem, Interoperability Is
One of the most misleading things in IP based workflows is when the transport looks perfect, zero packet loss on SRT, stable jitter, low and consistent RTT and yet the decoder still struggles.
Why? Because decoders aren’t parsing network packets, they’re parsing media streams embedded within them. And if the underlying stream structure isn’t something the decoder is built to handle, playback will stutter, freeze, or fail, even though the SRT transport layer did its job perfectly.
This is often caused by:
- Poorly muxed MPEG-TS: missing or infrequent PAT/PMT tables, non-aligned PCR/PTS/DTS, or broken continuity counters.
- Unexpected PCR jitter: even small inconsistencies in clock stability can throw off strict decoders, especially those in broadcast chain environments.
- Audio channel mismatches: for example, mono audio on a PID where the decoder expects stereo, or AAC-LC profiles where only HE-AAC is supported. Some operators are still even using MPEG-1 Layer 2 audio.
- GOP inconsistencies: especially in live encoders under fluctuating network or processing conditions, some decoders can’t tolerate GOP drift or irregular IDR (keyframe) intervals.
These issues aren’t visible at the ARQ or IP layer. The packets may arrive in perfect order, but if what’s inside the stream isn’t what the decoder expects, it will fail. It’s not about network integrity, it’s about stream compatibility.
That’s why transport level diagnostics aren’t enough. You need visibility into muxing behaviour, timestamp alignment, and how the decoder is interpreting the stream, not just whether it arrived.
What Can We Do About It?
At GlobalM, we take a pragmatic approach to this very common problem, recognising that encoder/decoder incompatibility is not something you can solve with standards alone, but with smart architecture and the right tooling.
- Cloud Based Edge Processing
By inserting a lightweight edge processing layer into the distribution path, we can remux, transcode, or version streams in real-time, tailoring each output to match the expected requirements of the receiving decoder. This allows us to create decoder specific variants of the stream without altering the original encoder output.
For example:
- If an IRD requires constant bitrate (CBR) and cannot handle variable bitrate, we can remux the stream into compliant CBR.
- If a decoder cannot receive 1080i in H.264, we can transcode to 1080p or another compatible format.
- If a decoder expects a particular audio layout or PID structure, we can reshape the stream accordingly.
By knowing in advance which decoder models are being used and what their expected receiving specifications are, we can resolve compatibility issues before they surface. This approach enables us to build a delivery network that supports a wide range of encoders and decoders from multiple manufacturers, without compromising performance or quality.
- Interop Profiles and Testing
We encourage customers to proactively test their encoder and decoder combinations ahead of live events. Differences in stream handling, such as bitrate control, muxing structure, or audio and resolution expectations can lead to playback issues that are difficult to diagnose in real time.
In general, when using the same brand and model for both encoder and decoder, interoperability is rarely an issue. Problems typically arise when mixing equipment from different vendors, each with their own assumptions and interpretations of the standards.
From experience, most decoder related issues can be avoided with early validation and a clear understanding of what each device expects. We’re available to advise and support customers through this process where needed.
- Encourage Buffer Flexibility
We strongly recommend configuring an adequate SRT Link Latency Buffer on the decoder side, typically around four times the measured RTT as a starting point. This simple setting dramatically improves playback stability under fluctuating conditions.
Some users push latency higher, sometimes beyond 1000ms which, depending on the decoder model, can introduce unintended buffer behaviour. Understanding how each device handles large buffers is key to preventing instability.
The Bottom Line
It’s not about blaming encoders or decoders, it’s about recognising that complexity happens in the margins. The best solution is architectural flexibility and being able to adapt to what’s actually in the field, rather than relying on what’s supposed to work in theory.
If you’re struggling with decoder compatibility or want to simplify how you deliver high-quality live video globally, talk to us. We’ve already solved this problem in production for some of the most demanding live events in the world.
