# OS04D10 + SSC377D: Persistent grain/temporal noise vs UNV stock firmware (~20x worse)

[byfaruk]

OS04D10 + SSC377D: Persistent grain/temporal noise vs UNV stock firmware (~20x worse)

Hardware

• Camera: Uniview IPC2124LB-ASF28K-A
• Sensor: OmniVision OS04D10 (4MP)
• SoC: Sigmastar SSC377D (Infinity6C)
• Firmware: OpenIPC + Majestic (Maruko ISP) — custom OS04D10 port

Problem

Same hardware on UNV stock firmware produces extremely clean images
(grass field, low light). On OpenIPC + Majestic with our OS04D10 port we get
heavy grain/temporal noise on flat textures.

Temporal noise (frame-to-frame Y_std on grass):

• UNV stock: ~0.23
• Our OpenIPC port (best result): ~4–7 → roughly 20× worse

What we tried (15+ iterations, none reached UNV level)

Sensor driver

• Rebuilt sensor_os04d10_mipi.ko with UNV stock 143-register init table
  injected as a hybrid → noise std 25 → 5.8 (5× better, still not UNV)
• Cross-sensor binaries (imx415/imx335) → color artifacts, rejected

ISP binary patches (os04d10.bin)

• AETarget ladder pulled down (daylight luma 252 → 215)
• ExposureLimit MinShutter 22000→100µs, gain_max 18→6
• Sharpness section transplanted from OS04A10 stock OpenIPC bin → Y_std 23→11
• NR3D / WDR / PFC transplants → made it worse (sensor-specific)

Runtime iqServer push (TCP 9876)

• Reversed the wire format: cmd(u32=5) + body_len + iq_body
• Push NR3D TfStrC=63 (max temporal NR) → Y_std 22 → 6
• fps=25 + cbr + bitrate=4096 → temporal_mean 8.2 → 3.28
• Adaptive NR3D (gain-aware switch)
• Pushed NRLumaAdv max, NRChromaPre=255, DPC disable, iframe-only, h264
  baseline, minQP/maxQP, VBR 8M–12M → none matched UNV stock

UNV stock payload replay

Captured 102 UNV GET responses from a working unit, replayed 18 of them as
SET packets. Worked for 14 (B/C/L/PFC/DynamicDP/NR3D/NRChromaPre/NRLumaAdv/
AETarget/AEConverge/AWBSpecialCase/AWBCTCali/Gamma/Sharpness). Failed for:

• Saturation → washed-out color
• NRChromaAdv (UNV [255,255,255,215,...]) → completely strips chroma
  in Majestic Maruko (B&W frame)
• AEPlainLong/ShortTbl → Majestic logs:
  [pAE_SetPlainShortExpTbl] HW:1024/259142/46/333333 TBL:1024/8192/30/1400 Plain Table is not valid!

Why it likely cannot be solved without OpenIPC-side work

1. AE engine mismatch — Majestic AE rejects UNV's plain tables because
   HW gain range (1024–259142) does not match UNV's table range (1024–8192).
2. NR pipeline override — pushing NR3D [15×16] at runtime, Majestic
   overlays its own ladder [15,15,...,25,29,30,35,55,55] regardless.
3. Closed proprietary middleware — UNV runs additional NR / DRC stages
   on top of Maruko ISP that are not exposed in OpenIPC.
4. Block-pattern noise — diff frames show 8×8 block patterns that are
   ISP-internal (not H.264), not fixable by raising bitrate.

Questions

1. Can Majestic's AE engine be modified to accept UNV-style plain exposure
   tables (or rescale them transparently)?
2. Any known method to integrate the proprietary UNV NR middleware (or
   equivalent) into the OpenIPC Maruko pipeline?
3. Is using Sigmastar's closed-source ISP firmware blob with OpenIPC on
   SSC377D feasible / permitted?

Attached

• sahacam-v1.0-baseline.bin, sahacam-v2.6-F.bin (our ISP binaries)
• sensor_os04d10_mipi.ko, sensor_os04d10_mipi.v1.3.ko (driver builds)
• sahacam-unv-stock-push-v2.8-F.sh (runtime push script)
• default_pic_OS04D10.xml, isp_api.xml (UNV reference)
• stock_os04d10_KEY_PARAMS.txt, versions.md (notes)

UNV stock firmware itself is AES-encrypted (entropy 7.998), cannot
share decrypted blobs.

@viktorxda @widgetii

sahacam-os04d10-debug.tar.gz

video link : https://t.me/c/1166652144/1/140348

[byfaruk]

This is my clearest .bin file.
@ZigFisher @widgetii

link : https://fromsmash.com/AdDYWDs1zB-dt