Field-order routing sends progressive-in-interlaced-carriage (PsF) H.264 to software for no visual benefit — #220 reprices the stated cost

[rrgomes]

VideoRoutingPolicy routes H.264 to software when the container or avcC declares a field order, so DeinterlaceFilter can run — tvOS AVPlayer will not deinterlace, and 1080i broadcast content otherwise combs. The rule is right, and its comment prices the false positive honestly: "A false positive only costs an unnecessary SW decode (deint=interlaced passes progressive frames through untouched), never a wrong deinterlace."

There is a systematic false positive, and #220 has changed what it costs.

PsF

Blu-ray has no 1080p25, so 25 fps European content is mastered as 1080i25: progressive pictures in interlaced carriage. The container and SPS declare it interlaced and they are not lying about the encoding — but the pictures are progressive, and nothing needs deinterlacing.

On a 46-minute 1080i25 H.264 episode from a European Blu-ray remux (DTS-HD MA 5.1, one PGS track):

ffprobe stream:  field_order=tt          container and SPS declare TFF interlaced
ffprobe frames:  interlaced_frame=0      every sampled frame, I/P and B

MediaInfo agrees with the container — Scan type: MBAFF / InterleavedFields / TFF, SEI pic_struct=3 — while every decoded frame comes out with equal field POCs and unflagged. Both tools are right at different layers.

The engine's own behaviour confirms it end to end. SoftwareVideoDecoder engages the filter only on flagged frames, so the graph never configures: logs from these sessions carry only the 64×64 warm-up probe and never a frame-size [Deinterlace] engaged line. The picture is correct, and the graph is right not to build. The content is decoded in software, and then nothing deinterlaces it.

What changed

Until now the cost of this false positive was one unnecessary software decode. #220 added a second cost: the software path with a subtitle track selected is where that issue lives, so the class of content that trips this rule for no benefit is also the class exposed to it. Independently, software-decoding 1080i25 H.264 alongside DTS-HD MA forgoes VideoToolbox and spends power and thermal headroom for a filter that never runs.

Proposal

The policy already has a hierarchy in which a concrete frames-analyzed PROGRESSIVE probe wins over the declared field order. Extending that probe to recognise PsF would take this class off the software path: decode a small sample and treat equal field POCs, or AV_FRAME_FLAG_INTERLACED unset across the sample, as progressive regardless of what the container declares. AVPlayer decodes MBAFF H.264 natively, and PsF needs no deinterlacing, so the result should be visually identical to what the software path produces today.

This is not a workaround for #220 and should not be treated as one. Genuinely interlaced content still routes to software with a subtitle track available — MPEG-2 576i here does build the graph at frame size — so whatever is eating the heap stays reachable regardless. The two are independent; I'd rather have both.

[superuser404notfound]

Confirmed, and the divergence is reproducible one layer deeper than the tools: it is two FFmpeg code paths reading the same SEI differently.

h264_parser.c (which feeds codecpar.field_order, the value the routing rule reads) sets AV_FIELD_TT for a FRAME-coded picture on SEI pic_struct == TOP_BOTTOM alone, weighing neither ct_type nor how the slices were actually coded. h264_slice.c (which feeds AV_FRAME_FLAG_INTERLACED) flags that same picture only when it is field- or MBAFF-coded, and a clock_timestamp carrying ct_type overrides even that. So MediaInfo and ffprobe are not disagreeing about the file, they are quoting two functions that were never going to agree on PsF, and routing was consuming the structurally less informed of the two.

The observation about the missing frame-size [Deinterlace] engaged line is what made the fix tractable, because it reframes the question. The engine does not have to decide whether the content is progressive, which is a judgement about pictures. It only has to answer the narrower question the rule actually rests on: will the deinterlacer ever engage. SoftwareVideoDecoder engages it on AV_FRAME_FLAG_INTERLACED and on nothing else, so a sample in which that flag never appears proves the software detour is a no-op for that stream, and the native path renders the same frames with hardware decode.

InterlaceProbe therefore decodes a short sample before routing and applies exactly that predicate. One consequence worth stating, because it is what makes the check safe rather than merely useful: since the probe's predicate is the runtime's predicate, its false positives are harmless by construction. A stream whose first frame is flagged only through libavcodec's prev_interlaced_frame = 1 decoder-init bias is precisely the stream on which the real software path would engage the filter at that same frame and latch it. Reporting "interlaced" there is agreement with the runtime rather than a miss.

Bounds:

• Only a clean sample overrules the declaration. Inconclusive (decoder open failed, read error, fewer than 12 frames decoded, budget expired) keeps the previous routing.
• A flagged frame ends the sample immediately, so genuinely interlaced material pays a frame or two of decode instead of a full sample.
• Seekable VOD only. The sample moves the read position of the demuxer the session reuses, and live 1080i broadcast, the case the rule exists for, is neither seekable nor mis-declared.
• Only the declared-interlace rule is overrulable. MPEG-2, VC-1, VP9 and AV1 without hardware never trigger a probe, since the answer could not change their route.

Verified end to end on synthesized 1920x1080 fixtures, both declaring field_order=tt. Progressive frames under that declaration now dispatch native and play clean with no frame-size deinterlace graph; genuinely interlaced frames still dispatch software and still log engaged [hardware]: 1920x1080. Probe cost on those fixtures, on Apple silicon: 29 ms for genuinely interlaced material (early exit on frame 1), 104 ms for a full 45-frame sample. skip_idct was measured and rejected, it changed nothing.

On the point that this is not a workaround for #220: agreed, and it was not treated as one. #220 was corrected independently in 5.24.0, where the persistent reader now requests bounded ranges instead of asking for the remainder of the file and trying to regulate the result with an advisory suspend(). Genuinely interlaced content still routes to software with a subtitle track available, so nothing about that path was made unreachable.

Released in 5.25.0 (5b6f44a).

A test on the 1080i25 episode itself would be valuable, both for the routing decision and for the picture: the expectation is a native dispatch and an image identical to what the software path produces today. The engine log line to look for is declared interlaced (fieldOrder=2) but progressive(framesDecoded: N); the deinterlacer would never engage, routing native for HW decode (#232).

Thank you for the analysis. Pricing the false positive honestly in the original comment, and then noticing when the price changed, is what surfaced this.