SRT Decoder Compatibility: Why Your Feed Breaks and How Transcoding Fixes It

The Hidden Compatibility Problem in SRT Distribution

SRT guarantees reliable delivery — retransmissions, encryption, congestion control. But reliable delivery doesn’t mean compatible delivery.

The same SRT stream can play perfectly on one decoder and produce a black screen on another, even with zero packet loss on the wire. The issue isn’t the transport. It’s what’s inside: H.264 profiles, chroma subsampling, interlaced vs progressive, audio codecs. These parameters vary between encoders and decoders, and the mismatches cause most of the unexplained failures in SRT distribution.

This article breaks down exactly which decoders support what, and how to solve compatibility issues with transcoding.

Why Decoders Disagree

H.264 vs H.265: Different Codecs Entirely

H.264 (AVC) and H.265 (HEVC) are completely different codecs. A decoder that only supports H.264 cannot decode an H.265 stream, and vice versa.

SRT doesn’t negotiate codec — it transports whatever the encoder sends. If the encoder outputs H.265 and the decoder only handles H.264, the SRT connection establishes fine — packets arrive, stats look normal — but the decoder shows no video.

H.264-only decoders (cannot receive H.265): Kiloview DC230, DC220, Matrox Monarch EDGE

H.265-only via SRT (cannot receive H.264 over SRT): Blackmagic Streaming Decoder 4K

Most other decoders handle both, but verify. The Blackmagic is a common gotcha — it accepts H.264 via RTMP but only H.265 via SRT.

H.264 Profiles

H.264 has multiple profiles that define which features the encoder can use:

When a broadcast encoder outputs H.264 High 4:2:2 profile, it produces a bitstream that is technically valid H.264 — but many decoders only support up to High profile (4:2:0). They do not implement the High 4:2:2 profile required to decode it.

What happens: The decoder connects to the SRT stream, receives packets, and either:

• Shows “no signal” or “unsupported format”
• Shows corrupted video with color artifacts (decoders that try anyway)
• Drops frames intermittently as it fails to decode certain NAL units

Interlaced vs Progressive

Not all decoders handle interlaced content correctly:

• Some decoders output progressive only and require deinterlacing, which they may or may not do well
• Some decoders drop the bottom field entirely, producing half-resolution output
• Some decoders report the stream as 1080p25 instead of 1080i50, causing downstream timing issues
• Some (like Evertz UXP-TRXS-HC) support interlaced decode only under H.265, not H.264

Interlaced is still the standard in European broadcast (EBU), but the IT side of the industry (IP decoders, web players, CDN ingest) has moved to progressive. If your distribution chain includes any IT-grade equipment, interlaced will cause problems.

Audio Codec Mismatches

Another common failure point:

If an encoder outputs MP2 audio (common in European broadcast) and a decoder only expects AAC, you get video but no audio — or garbled audio if the decoder tries to interpret MP2 as AAC.

Channel Count and Layout

Multichannel audio (5.1, 7.1) can also break decoders that only support stereo. Some decoders will silently downmix, others will drop all audio, and others will play only the first two channels at the wrong levels.

SRT Latency Mismatch

Not a codec issue, but it causes the same symptoms (dropped frames, choppy video):

If the decoder’s SRT latency buffer is too small relative to the network RTT, SRT cannot retransmit lost packets in time. The decoder receives an incomplete stream and drops frames. This looks like an encoding problem but is actually a network configuration issue.

Rule of thumb: SRT latency should be at least 3–4× the round-trip time (RTT) between encoder and decoder. For a 50ms RTT link, set latency to at least 200ms. For intercontinental links (150ms RTT), set it to 600ms+.

Decoder Compatibility at a Glance

Key limitations: The Blackmagic Streaming Decoder 4K only accepts H.265 over SRT (H.264 via RTMP only). The Makito X4 Decoder handles 1080i natively in HEVC but decodes H.264 as progressive only. The Matrox Monarch EDGE is H.264-only — no H.265 at all.

Detailed Decoder Specs by Brand

Kiloview

Key gotcha: The DC230 and DC220 are H.264-only, 4:2:0-only. The D350 supports 4K and H.265 but is limited to 4:2:0 8-bit for both H.264 and H.265 — it cannot decode 4:2:2 despite being a “4K decoder”. The N60 is the only Kiloview that handles H.264 High 4:2:2 and H.265 Main 4:2:2 10-bit.

Magewell

Key gotcha: Magewell doesn’t explicitly document H.264 4:2:2 support on their decode path. No MP2 audio support — if the source sends MPEG-1 Layer II audio (common in European broadcast), you’ll get video with no audio. The Ultra Encode and Ultra Stream are encoders only — they cannot decode SRT.

Haivision

Key gotcha: The Makito X4 Decoder is the reference SRT decoder — it handles virtually everything. If an MCR says “we have Haivision”, clarify which product: the Media Gateway / SRT Gateway is a protocol converter (SRT↔RTMP↔UDP), not a decoder. Play Pro is a monitoring app (iOS/Android), not production equipment.

Ateme

Key gotcha: Ateme is broadcast-grade and supports everything. But the Kyrion DR5000 requires a separate SRT license (DR5000-LIC-SRT). Without it, SRT is not available even if the hardware supports it. The CM5000 is an encoder only — not a decoder.

Blackmagic Design

Key gotcha: The Streaming Decoder 4K only accepts H.265 over SRT — H.264 is supported via RTMP only. If the source is H.264 over SRT, the output stays black. The Web Presenter HD and 4K are encoders, not decoders. The Teranex Mini SDI to IP uses proprietary TICO, not SRT.

Teradek

Key gotcha: The Prism Flex Mk II does not decode H.264 4:2:2 — only Baseline, Main, and High profiles (4:2:0). 4:2:2 10-bit is available in HEVC mode only. H.264 interlaced decoding falls back to software instead of hardware. The legacy Cube 625/675 decoders are discontinued (H.264 4:2:0 only, 1080p60 max).

Matrox

Key gotcha: One of the few decoders that explicitly supports H.264 High 4:2:2 profile. But it’s H.264 only — no HEVC/H.265 decode at all. If you plan to move to H.265 later, the Monarch EDGE can’t follow.

Evertz

Key gotcha: The XPS is full broadcast-grade (JPEG 2000, JPEG-XS, up/down/cross-conversion). The UXP-TRXS-HC supports 4K60 10-bit 4:2:2 but H.264 interlaced is not supported — interlaced formats work in HEVC mode only. Compressed audio is AAC only (2.0 and 5.1); PCM is available uncompressed.

Net Insight Nimbra 400

Key gotcha: The Nimbra 400 is a true encoder/decoder — not just a transport router. Up to 4 independent channels per 1U, with parallel encode and decode. SDI + ASI I/O. H.264 4:2:2 profile support is not documented (contact Net Insight). Strong in managed broadcast networks (sports, events) where RIST and Zixi are also used.

What Your Encoder Outputs

Decoder compatibility depends on what your encoder actually sends. Not all encoders expose the same options — some lock you into specific profiles, chroma, or audio codecs.

Important notes:

• Makito X is H.264-only, no 4:2:2 — the original Makito X encodes H.264 High Profile (4:2:0). It cannot output H.265. Still widely deployed in broadcast contribution. If your downstream decoder requires H.265 (like Blackmagic Streaming Decoder 4K), you need a transcoding gateway.
• Makito X4 interlaced depends on codec (both encoder and decoder) — HEVC encoding preserves interlaced (1080i50 in → 1080i50 HEVC out). H.264 encoding deinterlaces to progressive (1080i50 in → 1080p50 H.264 out). The X4 decoder mirrors this: HEVC interlaced decode is native, but H.264 decode is progressive only. If you feed a 1080i source to a Makito X4 encoder with H.264, the output is 1080p50 — confirm downstream decoders support progressive before assuming compatibility. Source: Haivision engineering.
• H.264 4:2:2 is only available from broadcast-grade encoders — Makito X4, Kiloview N60, Ateme CM5000. The Prism Flex outputs 4:2:2 in HEVC only. Prosumer encoders (ATEM Mini, Web Presenter HD, Kiloview E1/E2, Magewell Ultra Encode) output 4:2:0 only.
• MP2 audio comes from broadcast encoders — Prism Flex and Ateme CM5000 can output MPEG-1 Layer II. Most prosumer encoders default to AAC. If your decoder can’t handle MP2, the source is likely a broadcast contribution encoder.
• ATEM Mini Pro ISO supports SRT since firmware 9.5 — Blackmagic added SRT streaming support in ATEM Software 9.5 (2024). Both RTMP and SRT are supported. SRT configuration is done via Server/Key fields in ATEM Software Control.
• LiveU Solo / Solo Pro are NOT direct SRT encoders — they send proprietary LRT to LiveU Cloud, which converts to SRT. This requires a paid LRT subscription. The device never outputs SRT directly.

Encoder → Decoder Compatibility Cross-Reference

Instead of checking each encoder/decoder pair individually, match your encoder’s output profile to the decoder’s capabilities. Four output profiles cover most SRT distribution scenarios.

Which Profile Does Your Encoder Produce?

Does It Work?

How to read this: Find your encoder in the first table to identify your output profile. Look up your decoder in the matching column. “No” means you need a transcoding gateway between them. “Not verified” means the manufacturer doesn’t publicly document this capability — test before committing to production.

The Solution: Multi-Profile Transcoding

When you distribute to multiple destinations with different decoder capabilities, the answer is to transcode your single input into multiple encoding profiles, each matched to what the destination can handle.

SRT input (any broadcast encoder)
                    │
                    ▼
              Vajra Cast
                    │
      ┌─────────┬──┴──┬─────────┐
      ▼         ▼     ▼         ▼
  Passthrough  4:2:0  H.265    IT/CDN
  (original)   fix    transcode profile
      │         │       │        │
      ▼         ▼       ▼        ▼
  Broadcast   Prosumer  H.265   CDN
  decoders    decoders  only    ingest

• Passthrough sends the original quality to broadcast-grade decoders that handle everything — zero CPU cost
• 4:2:0 fix converts 4:2:2 → 4:2:0 and transcodes audio to AAC for standard H.264 decoders
• H.265 transcode converts H.264 → H.265 for decoders that only accept HEVC over SRT
• IT/CDN profile deinterlaces to progressive, converts to 4:2:0, transcodes audio to AAC for web/CDN equipment

Resource Cost

CPU cost per profile (software encode), or near-negligible with Intel QSV:

With hardware transcoding (Intel QSV), a single server can handle 4-8 simultaneous transcodes of 1080p50 content.

Worked Examples

4:2:2 Rejection

Setup: Encoder outputs 1080i50 H.264 High 4:2:2, 25 Mbps. Destination has a Magewell Pro Convert H.26x to SDI.

Symptom: Video output shows corrupted colors or a black screen. SRT connection is established, stats look normal.

Diagnosis:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=profile,pix_fmt \
  -of csv=p=0 "srt://source:9000?mode=caller&latency=500000"

Output: High 4:2:2,yuv422p — confirms the source sends 4:2:2. The Magewell doesn’t document 4:2:2 decode support.

Fix via gateway: Transcode to H.264 High 4:2:0, keep everything else.

ffmpeg -i "srt://:9000?mode=listener&latency=500000" \
  -c:v libx264 -profile:v high -pix_fmt yuv420p -b:v 20M \
  -flags +ilme+ildct -top 1 \
  -c:a copy \
  -f mpegts "srt://decoder:9000?mode=caller&latency=300000"

Cost: ~5% GPU with Intel QSV. Video quality loss is minimal — chroma detail reduction is invisible on most content.

H.265-Only Decoder

Setup: Encoder outputs H.264 over SRT. Destination has a Blackmagic Streaming Decoder 4K.

Symptom: Black output. The SRT connection establishes normally and stats look fine, but the decoder produces no picture.

Why: The Blackmagic Streaming Decoder 4K only accepts H.265 over SRT. H.264 is supported via RTMP only.

Fix via gateway: Full codec transcode — H.264 → H.265, deinterlace if needed, audio to AAC.

ffmpeg -i "srt://:9000?mode=listener&latency=500000" \
  -vf yadif=1 \
  -c:v libx265 -profile:v main -pix_fmt yuv420p -b:v 8M \
  -c:a aac -b:a 256k -ac 2 \
  -f mpegts "srt://decoder:9000?mode=caller&latency=300000"

Cost: ~15% GPU with Intel QSV. This is the heaviest transcode (codec change + potential deinterlace) but still manageable on a single server.

Audio Mismatch

Setup: European broadcaster, encoder outputs MP2 audio (MPEG-1 Layer II). Destination has a Teradek Prism Flex Mk II.

Symptom: Video plays fine. No audio. Or garbled noise instead of audio.

Why: Teradek only supports AAC-LC audio. MP2 is standard in European broadcast but unsupported by most prosumer/IT decoders. The decoder receives audio packets it can’t interpret.

Fix via gateway: Audio-only transcode — video passthrough, MP2 → AAC.

ffmpeg -i "srt://:9000?mode=listener&latency=500000" \
  -c:v copy \
  -c:a aac -b:a 256k -ac 2 \
  -f mpegts "srt://decoder:9000?mode=caller&latency=300000"

Cost: Negligible. Audio transcoding barely registers on CPU or GPU.

Multi-Destination Distribution

When distributing to multiple destinations simultaneously, the gateway creates one output per destination, each with its own transcoding profile:

Total GPU load: ~34% on a single Intel QSV-capable server. One input, five outputs, every destination gets a compatible feed.

Diagnosing Existing Problems

1. Identify the Encoding Profile

Check what the encoder is actually outputting:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=profile,pix_fmt,width,height,field_order \
  -of csv=p=0 "srt://source:9000?mode=caller&latency=500000"

Output example:

High 4:2:2,yuv422p,1920,1080,tt

yuv422p = 4:2:2. yuv420p = 4:2:0. tt = top-field-first (interlaced).

2. Test Decoder Capabilities

Send a known-good 1080p 4:2:0 H.264 stream to the failing decoder. If that works, the issue is 4:2:2, interlaced, or audio — not SRT or network.

ffmpeg -f lavfi -i testsrc=size=1920x1080:rate=50 \
  -c:v libx264 -profile:v high -pix_fmt yuv420p -b:v 8M \
  -f mpegts "srt://decoder:9000?mode=caller&latency=500000"

3. Check SRT Statistics

On the decoder side (or in Vajra Cast’s dashboard):

• RTT: what’s the actual round-trip time?
• Packet loss: is SRT recovering it within the latency buffer?
• Retransmission rate: high retransmission with zero loss = SRT is working. High retransmission with non-zero loss = latency buffer too small

4. Check Audio

Many “no signal” reports are actually audio issues. Some decoders require audio to be present and in a specific codec. If the audio is in a format the decoder doesn’t support, some decoders refuse the entire stream.

5. Systematic Codec Isolation (One Variable at a Time)

When facing unexplained failures between a specific encoder and decoder pair, isolate the issue by starting with the most compatible settings and changing one variable at a time:

1. Baseline test: H.264 Baseline, 4:2:0, 8-bit, 720p progressive. This is the lowest common denominator — if this fails, the problem is transport, not codec
2. Add resolution: switch to 1080p. If it breaks, the decoder has a level or resolution issue
3. Add chroma: switch to 4:2:2. If it breaks, the decoder doesn’t support High 4:2:2 profile
4. Add interlaced: switch to 1080i50. If it breaks, the decoder can’t handle interlaced content
5. Change codec: switch to H.265. If it breaks, the decoder doesn’t support HEVC

This isolates the exact parameter causing the failure — much faster than debugging everything at once.

On hardware encoders like the Makito X4, use the Resolution drop-down to downscale and deinterlace (e.g., select 720p to confirm basic compatibility before testing 1080i50).

Key insight: If SRT statistics (RTT, loss, retransmission) look clean but the decoder shows no video or corrupted output, the problem is almost certainly codec/profile incompatibility, not transport. Don’t waste time tuning SRT latency when the issue is inside the payload.

Common Compatibility Fixes

Summary

SRT compatibility issues come from what’s inside the transport — H.264 profiles, chroma subsampling, scan mode, audio codecs — not from SRT itself. When distributing to mixed decoder environments, a transcoding gateway between encoder and decoders resolves most failures: passthrough for capable endpoints, transcoded profiles for the rest.