nx_yuvgen.nx

nx_yuvgen.nx -- synthesise a YUV420p test clip so the videocodec gates can RUN on the NAS. WHY THIS EXISTS. 17 videocodec gates all open /mnt/c/Users/elder/nishi-core/nxc2/knowledge/staging/media/bframe_test_decoded.yuv a HARDCODED LAPTOP PATH. Execution moved laptop->NAS and the asset did not follow, so all 17 return "cannot read yuv -> RED" with pass=0/0 -- ZERO teeth run. That is a gate that never executed, not a gate that failed, and it is currently what blocks EVERY deploy in the ecosystem through the nx_deploy_ready evidence-honesty check. The file is absent from the LAPTOP too, so the evidence has been unreproducible for some time and the RED is honest. WHY SYNTHETIC IS THE RIGHT ANSWER, NOT A COMPROMISE. These benches measure codec BEHAVIOUR -- B-frame vs P-chain at matched PSNR, decode parity, motion-vector cost. That needs real MOTION, not a real movie. A generated clip with KNOWN, CONTROLLED motion is a better instrument than an arbitrary video: the ground truth is exact, it is hermetic, it costs no 10MB asset transfer, and it cannot silently change under you. Same reasoning that made nx_q4k_dot_simd runnable with synthesised Q4_K blocks instead of a 1.1GB model. CONTENT (deliberately non-degenerate -- a flat or static clip would make the comparison meaningless): - a fixed diagonal gradient background, so intra prediction has real structure to model; - a bright block TRANSLATING a few pixels per frame, so motion estimation has a true displacement to find and B-frames have something to interpolate that P-chains must code; - a slow luma pedestal drift, so rate control sees frame-to-frame change. U/V carry a mild spatial ramp plus a per-frame tint so chroma is exercised rather than constant. argv: <outpath> [W] [H] [frames] defaults 576x1024x16 (the gates need >=12). Writes plain YUV420p: Y plane W*H, then U and V each (W/2)*(H/2), per frame, no header. license_tier: ORIGINAL No hw writes (Rule 26).