java-topology/defects/x265-scan/CLEAN.md

3.1 KiB

x265 (libx265 / HEVC Reference Encoder) — 5-MOAD Scan Result: CLEAN

Scanned: 2026-03-31 Repo: https://github.com/videolan/x265 (depth=1) Language: C++

MOAD-0001 (CWE-407): CLEAN

x265 is a pure H.265/HEVC video encoder. All hot-path collection scans are bounded by HEVC spec constants:

  • m_numRefIdx[list] bounded by MAX_NUM_REF = 16 (HEVC spec)
  • RPS::sortDeltaPOC() in common/slice.cpp: insertion sort over numberOfPictures (max 16 entries per HEVC spec) — O(16^2) = constant 256 comparisons, never O(N^2) at scale
  • DPB::applyReferencePictureSet() in encoder/dpb.cpp: O(F * R) where F = DPB frames (bounded by maxDecPicBuffer <= 16) and R = RPS size (<= 16) — O(256) constant
  • DPB::computeRPS(): single O(F) pass over DPB linked list, F bounded by 16
  • MotionEstimate candidate dedup in encoder/motion.cpp line 800: O(C) pass over candidates where C is small (4-8 spatial neighbors); no inner O(C) membership scan
  • RateControl::getZone() in encoder/ratecontrol.cpp: O(Z) scan over user-defined zones, called ~4 times per frame. O(F * Z) total, not O(F^2) or O(Z^2). Called in the RC path (not motion estimation inner loop); Z is typically small (< 100 for VOD workflows). Borderline, not a confirmed CWE-407 — the zone scan is not inside a per-element inner loop.
  • Analysis::findSameContentRefCount() in encoder/analysis.cpp: O(2 * R) where R = numRefIdx, bounded by 16

No unbounded O(N^2) list membership patterns found in hot encode path.

MOAD-0002 (Intertangle): CLEAN

Encoder in encoder/encoder.h is a per-encoder instance object. Each x265_encoder opaque pointer wraps a single Encoder instance. Frame encoders (FrameEncoder) are worker objects coordinated through ThreadPool. No global singleton shared mutable state between independent encoder instances.

MOAD-0003 (Leaked Context): CLEAN

ThreadLocalData in encoder/analysis.h is per-CTU-row work state: it holds Analysis objects and scratch buffers scoped to one frame-encoding row. It carries no request-scoped identity (user ID, session token, tenant context). It is not a ThreadLocal in our MOAD-0003 sense — it is work state, not identity.

MOAD-0004 (CWE-312 Logged Secret): CLEAN

x265 is a pure codec library with no authentication or credential data flows. x265_csvlog_encode() in encoder/api.cpp writes argv[] to a CSV file — this dumps CLI arguments including filenames. Input filenames could theoretically contain embedded credentials (rtsp://user:pass@host/stream) but this is a codec CLI convention issue, not a logging defect in our library code. The output goes to a CSV file, not a centralized log stream. Not a MOAD-0004 finding.

MOAD-0005 (Thundering Herd): CLEAN

x265_encoder_encode() is documented as not thread-safe per-encoder-instance. Our frame free-list access (m_dpb->m_freeList) occurs under this single-threaded API entry contract — no concurrent get+null+compute+put pattern. Frame-level parallelism is internal to the encoder with proper Lock/atomic primitives (m_sliceQpLock, m_sliceRefIdxLock, etc. in encoder/encoder.h).