marfrit/daedalus-fourier
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

h264: Intra_16x16 luma prediction — 4-mode C reference + spec gates

Browse Source 
Second piece of the intra-prediction primitive set after PR #12
(Intra_4x4 luma 9 modes).  Covers the Intra_16x16 luma MB type
per H.264 §8.3.2: 4 modes (Vertical, Horizontal, DC, Plane).

Scope:
  - tests/h264_intra_pred_16x16_ref.c — 4 spec-derived modes.
    Same FFmpeg-style interface as the 4x4 sibling:
      void daedalus_h264_pred_16x16_<name>_ref(uint8_t *dst, ptrdiff_t stride);
    Assumes all neighbours valid (interior-MB case).

    The Plane mode is the algorithmically heaviest of the four —
    spec §8.3.2.4 has two slope sums (H, V) over the asymmetric
    top/left contexts, a clipped quadratic evaluation per cell,
    and a top-left-corner participant at i=7 / j=7.  Implementation
    follows the spec straightforwardly with `clip_u8` on the final
    saturating cast.

  - tests/test_intra_pred_16x16.c — 5 test cases:
      * V, H, DC: standard contexts (gradient top / gradient left /
        small uniform pair).
      * Plane (uniform): all neighbours = 100 → H = V = 0 →
        output = (16*200 + 16) >> 5 = 100.  Verifies the
        orientation-free portion of the formula.
      * Plane (gradient): top + left both 0..15, spec-derived
        corner expectations pred[0][0] = 1 and pred[15][15] = 31.
        The arithmetic chain (H = V = 400 → b = c = 31, a = 480)
        is fully hand-traced in the test comment so the expected
        values are auditable.

  - CMakeLists.txt — new test_intra_pred_16x16 binary; pure-CPU
    library, no daedalus_core dependency (same separation as the
    4x4 ref).

Verified on hertz:

  $ ./build/test_intra_pred_16x16
    Vertical (mode 0)              PASS
    Horizontal (mode 1)            PASS
    DC (mode 2)                    PASS
    Plane (mode 3, uniform)        PASS
    Plane (mode 3, gradient)       PASS (corners 1, 31)

  ALL Intra_16x16 mode references PASS

Plane mode being right first try is meaningful — H/V sums, b/c
slope shifts, and the a-baseline arithmetic have many sign / index
error opportunities.  The asymmetric gradient test would have caught
any of them; it didn't.

What this does NOT cover (still in the intra-pred backlog):
  - Intra_8x8 chroma (4 modes per H.264 §8.3.3).
  - Intra_8x8 luma (High profile, 9 modes per §8.3.2.1 + the 1-2-1
    smoothing pre-filter — distinct algorithm from Intra_4x4).
  - Neighbour-availability fallback for boundary MBs.
  - Dispatch wrappers (same architectural question as before — wait
    for decoder Stage 2a strategy decision).
This commit is contained in:
Claude (noether)
2026-05-25 00:35:24 +02:00
parent fad600000b
commit c43ee84d8e
3 changed files with 281 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CMakeLists.txt
+8
View File
@@ -540,6 +540,14 @@ add_executable(test_intra_pred_4x4
)
target_compile_options(test_intra_pred_4x4 PRIVATE -O2)
# H.264 Intra_16x16 luma prediction (4 modes: V, H, DC, Plane) —
# reference + tests. Same spec-gate role as the 4x4 sibling.
add_executable(test_intra_pred_16x16
tests/test_intra_pred_16x16.c
tests/h264_intra_pred_16x16_ref.c
)
target_compile_options(test_intra_pred_16x16 PRIVATE -O2)
add_executable(bench_pool_overhead tests/bench_pool_overhead.c)
target_link_libraries(bench_pool_overhead PRIVATE daedalus_core)
target_compile_options(bench_pool_overhead PRIVATE -O2)