Fix --field interlaced encoding: frame skipping/hang (#981), pic_struct and bff field order (#982)

[Akilan-Sivakumar]

Summary

--interlace tff|bff --field was unusable from the CLI. It skipped every other input frame and never exited (#981). It also signalled every field with frame-only pic_struct values and encoded bff sources with the top field first (#982). This PR fixes all three problems in three separate commits:

Commit	Issue
Fix --field CLI skipping every other frame and hanging	#981
Fix pic_struct for --field to signal top/bottom field	#982 (part 1)
Fix --field bff to use the bottom field as the first field	#982 (part 2)

Issues and root cause

#981: every other frame skipped, CLI hangs

In --field mode each input frame is split into two fields, and encoder_encode is called once per field. The input queue counters m_picIdxReadCnt and m_picReadCnt were incremented inside that same per-field loop, so they advanced twice per input frame.

The CLI input queue has a single slot. The Reader took the first increment to mean "slot free" and loaded the next frame, then overwrote it with the following frame after the second increment. So every other frame was dropped: woven output frame i matched source frame 2i.

The counters then ended up out of step, and the process hung in one of two ways, depending on thread timing:

• Reader kept up: the encoder waited forever in readPicture. The Reader stops at the frame limit without setting m_inputOver.
• Reader fell behind: the read count passed the write count, so readPicture reported end of input early. The encoder flushed a partial stream (the "26 fields" in the issue). AbrEncoder::destroy then blocked in pthread_cond_destroy on m_picIdxReadCnt while the Reader was still waiting on it. This was confirmed with gdb.

#982 part 1: wrong pic_struct

The SPS sets field_seq_flag = 1, meaning every picture is a field. The --field branch, however, wrote pic_struct 3/4 ("top/bottom field, in that order"), which H.265 Table D.2 only allows for frames (field_seq_flag = 0). Decoders could not determine field parity.

#982 part 2: bff fields in the wrong order

The CLI field split always filled the first field from row 0 (the top field), whatever the --interlace mode. With bff, the first field is signalled as bottom but held the top rows. Decoders swapped the lines of every frame, and the fields were coded in the wrong temporal order.

Fix

• CLI --field mode skips every other input frame and hangs before the end of the input #981: release the input slot once per frame, after the last field:

  if (inputNum == inputPicNum - 1)
  {
      m_parent->m_picIdxReadCnt[m_id][idx].incr();
      m_parent->m_picReadCnt[m_id].incr();
  }

• --field: pic_struct 3/4 signalled with field_seq_flag=1, and bff fields mislabelled #982 part 1: signal pic_struct 1 (top) or 2 (bottom) from the field number. For tff the first field is top; for bff it's bottom. This matches what the existing --no-field interlaced path already writes.

• --field: pic_struct 3/4 signalled with field_seq_flag=1, and bff fields mislabelled #982 part 2: for bff, start the first field at row 1 (odd rows = bottom field) and the second at row 0. The change applies to every plane. tff is unchanged.

Progressive encoding and the --no-field interlaced path are not affected.

Testing and results

Compared against origin/master (f2cf32d).

Test	master	this PR
Issue command lines (tff/bff, --bframes 0, --frame-threads 1 --no-wpp, raw YUV)	hangs, frames dropped	exits, all 60 fields encoded
pic_struct with --field	3/4	1/2
bff first field vs source bottom field	top field coded first	44.2 dB match
Real 1080i content: 2 TFF clips and 1 BFF clip, --field vs ffmpeg-split --no-field reference	hangs	bit-identical (except the options SEI), identical HM decoded output
Progressive (3 clips) and --no-field interlaced	-	bit-identical to master
10-bit, 12-bit and multilib builds	-	build clean; --field tff/bff bit-identical to the reference

Fixes #981
Fixes #982