Interlaced H.264 and HEVC: What Your 1080i Streams Actually Contain

Why You Still Receive 1080i

Interlaced video was supposed to disappear a decade ago. It did not, and it will not for another decade.

The reason is not inertia. It is amortisation. A broadcast facility built around 1080i50 or 1080i59.94 has cameras, routers, SDI infrastructure, graphics systems and playout servers that were specified, purchased and depreciated over twenty or thirty years. National delivery specifications in Europe and North America still name interlaced formats. Sports contribution feeds still arrive interlaced because that is what the truck produces and what the rights holder wrote into the contract.

So while every web platform, every mobile app and every modern codec has moved to progressive, the feeds arriving at your gateway are still, very often, 1080i. Your job is not to have an opinion about that. Your job is to handle it without degrading it.

That starts with knowing what you actually received — and this is where most operators are working with a mental model that is too simple.

“1080i H.264” Describes Three Different Things

When your monitoring reports a stream as 1080i H.264, it has told you the presentation format. It has not told you how the encoder structured the video, and H.264 offers three legitimate ways to do it.

Frame coding with adaptive field structure (MBAFF)

Macroblock-Adaptive Frame/Field coding keeps both fields inside a single coded picture, then decides per region whether that part of the image is better coded as a frame or as a pair of fields. Static areas get frame coding, which is more efficient. Moving areas get field coding, which avoids wasting bits on comb artefacts.

This is the most efficient interlaced mode and the most common in professional contribution encoders. It is also the most demanding on decoders, because the structure changes across the picture.

Picture-adaptive coding (PAFF)

Picture-Adaptive Frame/Field coding makes the same choice once per picture rather than per region. Each picture is coded either as a full frame containing both fields, or as two separate field pictures, and the encoder switches as the content changes. Simpler than MBAFF, slightly less efficient, very widely supported.

Pure field coding

Every field is coded as its own picture, half height, at field rate. A 1080i50 stream becomes a sequence of 1920×540 pictures, fifty of them per second. Less common in H.264, because MBAFF and PAFF usually do better — but perfectly valid, and, as we are about to see, the only option HEVC gives you.

Why this matters: all three structures are correctly described as “1080i H.264”, all three decode to the same pictures, and they are not equally supported by every decoder in your chain. When a hardware receiver misbehaves on one feed and not on another that looks identical on paper, the coding structure is one of the first things worth checking — before the bitrate.

HEVC Interlaced: One Path, and It Surprises Everyone

HEVC was standardised at the moment the industry had decided the future was progressive. The committee made a deliberate choice: HEVC has no interlaced coding tools at all. No MBAFF, no PAFF, no equivalent.

What HEVC has instead is metadata. An encoder may code each field as a separate picture and signal, inside the stream, that these pictures are fields — with their parity and their intended display pairing.

The consequence is direct, and it catches almost everyone the first time:

An HEVC “1080i50” stream is a sequence of 1920×540 pictures at 50 pictures per second.

Not 1920×1080. Not 25 frames per second. Every analysis tool you point at it will report 540 lines, and the natural reaction is to assume something is broken, or that someone sent you a half-resolution feed. Nothing is broken. That is what interlaced HEVC is.

Two practical consequences follow.

Aspect ratio must be signalled explicitly. A 1920×540 picture with square pixels describes a 32:9 image. Interlaced HEVC therefore carries a pixel aspect ratio declaring that each pixel is twice as tall as it is wide, so the reconstructed frame is 16:9. Lose that signalling anywhere in the chain — and it is easy to lose — and the picture arrives stretched, while every bitrate and continuity check stays green.

Your monitoring has to understand what it is looking at. A system that classifies streams by raster alone will file interlaced HEVC as “540p50 progressive” and make every downstream decision on that false premise. Correct handling starts with correct recognition.

The Hardware Support Cliff

Here the two codecs diverge sharply, and a plan that looked reasonable on paper meets reality.

H.264 interlaced encoding exists in some hardware encoders, usually through a dedicated code path with its own constraints. Available, but neither default nor universal.

HEVC interlaced encoding is another matter. Because the standard has no interlaced tools, hardware vendors had little incentive to implement the field-sequence path, and most never did. NVIDIA’s encoders do not encode interlaced video at all — a limitation that has produced years of unresolved threads on their own developer forums. Intel’s HEVC hardware path does not encode fields either.

The practical consequence for an operator: producing interlaced HEVC is a software encoding job. There is no hardware shortcut. That single fact reshapes any capacity plan built around GPU-accelerated transcoding, because the channel count per server is now set by CPU, not by silicon.

Nobody tells you this in advance. You discover it when the encoder refuses the configuration — or worse, when it silently produces a progressive stream that everything downstream politely mislabels.

Three Decisions, and Only Two Are Reversible

Faced with an interlaced input, an operator has three options. They are not equivalent, and the difference is widely misunderstood.

Preserve the fields

Interlaced in, interlaced out, fields passing through the chain untouched in their temporal order. Nothing is invented, nothing is discarded. This is the right choice whenever the destination is a broadcast receiver, an SDI conversion, or an onward contribution link.

It is also the only temporally lossless option: every one of the fifty motion samples per second the camera captured is still there at the far end.

Convert to progressive

The fields are combined into full frames — the right choice when the destination is a web platform, a mobile app, or any modern distribution workflow.

Done properly, this conversion loses nothing in time: a 1080i50 feed deinterlaced at field rate becomes true 1080p50 — one frame per field, all fifty motion samples per second intact. Deinterlacing to 25 frames per second, which many systems do by default, throws away half the motion and makes sport look broken. The frame rate of the result is a choice, and the right answer for live content is almost always the field rate.

This decision is irreversible. Deinterlacing invents information: it reconstructs the missing lines of each field by interpolation. Re-interlacing afterwards does not bring back what was discarded — it produces a stream that is structurally interlaced but built from interpolated content. Two conversions in a chain cost twice, and no later stage can undo them.

The frequency with which this happens by accident is the single most common quality problem in live chains. A system that deinterlaces by default, because progressive is simpler to handle internally, silently degrades every interlaced feed that crosses it — and the loss never shows on a bitrate graph.

Convert progressive to interlaced

A progressive source must feed an interlaced destination — 1080p50 into a 1080i50 delivery spec being the everyday case. Done properly, fluidity is fully preserved: each field is taken from a distinct source frame, so all fifty motion samples per second survive the conversion. What is traded away is vertical resolution within each instant, which is the definition of interlacing, not a defect of the conversion.

The operation carries one non-obvious requirement: the vertical detail of the progressive image has to be filtered before the fields are built. Skip it and fine horizontal detail flickers between fields — the classic interlace twitter, painfully visible on graphics and lower thirds. Skipping that filter is the most common mistake in progressive-to-interlaced conversion.

What a Live System Has to Get Right

None of this is exotic. It is the ordinary condition of live contribution in 2026, and it defines what a gateway must do properly rather than approximately.

Recognise the structure, not just the raster. Knowing a feed is 1080i is not enough. A system needs to tell an H.264 frame-coded interlaced stream from a native HEVC field sequence, because they are the same programme in radically different shapes, and they need different handling downstream.

Preserve by default, convert on purpose. Deinterlacing should be a decision the operator takes, visible in the configuration — not a side effect of an internal simplification.

Never deinterlace in order to re-interlace. When input and output are both interlaced, the fields should travel through untouched. A deinterlace-then-reinterlace cycle spends quality and CPU to achieve nothing, and it is a surprisingly common pattern in systems designed progressive-first.

Signal correctly on the way out. Field order, field-sequence metadata and pixel aspect ratio are not decoration. They are what tells the receiver how to reassemble the picture. A stream carrying the right pixels with the wrong signalling is a broken stream to every device that reads it.

Verify the output; never assume it. Encoder documentation and encoder behaviour do not always agree — least of all on interlaced paths, which are the least travelled and least tested in every codebase. The only reliable evidence that a chain produces correctly signalled interlaced video is to encode, analyse the result, and confirm it.

Where Vajracast Fits

Vajracast treats interlaced H.264 and interlaced HEVC as first-class formats, not as edge cases to normalise away.

Interlaced inputs are identified by their actual coded structure — including native HEVC field sequences that other systems mistake for half-height progressive video. Interlaced-to-interlaced routing preserves the fields end to end, with no deinterlace cycle hidden in the middle. Deinterlacing to progressive is available where the destination requires it — including 1080i50 to true 1080p50 at full motion rate — as an explicit operator choice rather than a silent default. The reverse conversion, 1080p50 to a fully signalled 1080i50 output, is equally supported for progressive sources feeding interlaced delivery specifications. And every interlaced output path is qualified against the actual encoder binaries shipped with the platform, because on interlaced paths, specification and implementation are not always the same thing.

If your contribution feeds are interlaced and your destinations are mixed, that is not a problem to work around. It is the normal state of live broadcast — and it is what the platform is built to handle.

Related reading: Hardware transcoding with Intel Quick Sync · SRT decoder compatibility and transcoding