Interlaced live H.264 with unknown demuxer field_order stays on native decode (AVPlayer/VideoToolbox), produces persistent green colour cast #150

What happened?

Some interlaced live H.264 channels show a persistent green colour cast from the first frame, sustained throughout playback — not a transient flash, not blocky/glitchy corruption, and not explained by bad colour VUI (both the affected and a clean comparison channel report identical, correct BT.709 limited-range tagging).

Root cause, confirmed by comparing SPS across an affected channel and a clean one: the affected channel's SPS has frame_mbs_only_flag=0 — it's genuinely interlaced at the bitstream level. Per #107, interlaced content is meant to route to software decode, since AVPlayer/VideoToolbox on tvOS doesn't deinterlace. That routing rule is keyed off the demuxer's own field_order probe (TT/BB/TB/BT). On this stream, the demuxer's field_order came back UNKNOWN rather than a concrete value, even though the SPS unambiguously marks the content as interlaced. Because the rule only checks field_order and not the SPS's own frame_mbs_only_flag, the channel stayed on native/VideoToolbox decode, and the resulting output has the incorrect colour cast.

I expected interlaced content to route to software decode per #107 regardless of whether the demuxer's separate field-order probe resolves; instead, an inconclusive field_order silently defeats that routing decision even when the SPS itself is decisive.

Steps to reproduce

1. Tune a live H.264 channel whose source is interlaced at the SPS level (frame_mbs_only_flag=0) but where the demuxer's own field-order detection returns UNKNOWN rather than TT/BB/TB/BT.
2. Observe the routing dispatch log: dispatch: codec=27 → native with fieldOrder=0 (UNKNOWN).
3. Compare against a genuinely progressive channel on the same provider: same dispatch path (native), correctly so, with fieldOrder=1 (PROGRESSIVE).
4. On the interlaced-but-misrouted channel, observe a persistent green cast on screen from the first frame, sustained throughout — confirmed via screen recording, and confirmed not present when the same TV/HDMI setup plays other content via a different app (rules out display/HDMI).

AetherEngine version or commit SHA

5.8.5

Host app

Custom / my own integration

Platform

tvOS

OS version

tvOS 26.6 (beta)

Device / chip

Apple TV 4K (A15)

Playback path

Native AVPlayer

Source media (for playback bugs)

MPEG-TS live source (UK terrestrial simulcast via Xtream-style IPTV provider), H.264 Main profile, 1920x1080, both channels below from the same provider for direct comparison:

dispatch: codec=27 → native
fieldOrder=0 (UNKNOWN)
No decode errors, no SPS/PPS reference errors, no parse failures — the stream decodes "successfully" in the sense that nothing errors, but the output is visually wrong. This is a routing-decision bug, not a decode-error bug, which is why it produces no error-level log lines at all.