社区对 SSC336Q 的了解

摘自 Tino Darkness 在 OpenIPC Telegram 群组中的消息。每一条都链接到其出处消息。

• SSC336Q is H.264 only, max 3M@30, per the SSC336D/SSC336Q product brief. (消息 1)
• (Infinity6E family) Infinity6E (I6E) covers SSC30KD, SSC30KQ, SSC338 and SSC339; it is a different family and SDK from the I6 SSC325. Tino lists it as a separate family from I6B0 (SSC335) and I6C (SSC377/378). (消息 1, 消息 2)
• (Infinity6E family) The I6E SDK codename is Pudding, and SigmaStar demo code for I6E lives under "alderaan" ("jedi" is for I6B0). (消息 1, 消息 2, 消息 3)
• (Infinity6E family) The same Majestic build serves SSC338, SSC339 and SSC30Kx, all I6E (Pudding). As far as Tino knew in 2024-04, only I6E and I6B0 SigmaStar SoCs were supported in OpenIPC. (消息 1, 消息 2)
• (Infinity6E family) SSC336/338/339 have proprietary 0.5-1 TOPS hardware NN accelerators, and as Tino understands it SSR6xx, SSC336 and SSC338 should share the same AI core. (消息 1, 消息 2)
• (Infinity6E family) Tino said the SigmaStar DLA/IPU model tool (SGS tools page in the Pudding docs) seems to require a separate NDA and is not free (2024-02). (消息 1)
• (Infinity6E family) Pudding SDK documentation is published at wx.comake.online/doc/doc/SigmaStarDocs-Pudding-0120/, but as of 2026-08 CoMake's new website has no Pudding SDK download (only SSC305/309 for camera SoCs). (消息 1, 消息 2)
• (Infinity6E family) Infinity6E uses dynamic voltage and frequency scaling (DVFS). (消息 1)
• (Infinity6E family) On an Anjoy board the core voltage is selected by PAD_PM_GPIO7/8 through a device-tree table, vid_voltages = <850 900 950 1000>. Tino calls changing the top entry from 1000 to 1050 'a way to fry your SoC', and says to do it only if TEMP_R is not too high. He says this should apply to most Infinity6 chips and gives 1.05 V as the max. (消息 1, 消息 2)
• (Infinity6E family) Devices with secure boot enabled require signed, or signed and encrypted, binaries (see the SSC9381G/9351 Pudding OTP-Key docs). (消息 1)
• (Infinity6E family) SigmaStar boot-select straps offer more than two combinations (NOR, NOR+SD, NAND, ...). (消息 1)
• (Infinity6E family) For a native FPV venc on I6E, start from st_main_venc.c in the SDK, a simple ~2 KLoC source; the venc and other hardware blocks are documented in the Pudding mi_venc docs. (消息 1, 消息 2)
• (Infinity6E family) I6E and I6B0 use the "old" style SigmaStar ABI, e.g. MI_VENC_CreateChn(VeChn, pstAttr) without a device argument. (消息 1)
• (Infinity6E family) It looks like the OpenIPC SDK headers are closer to I6B0 (Ispahan) than I6E (Pudding), so some enums/structs will not match exactly. In some SDK versions (he remembers I6B0 and I6E) functions are declared in headers but missing from the .so. (消息 1, 消息 2)
• (Infinity6E family) On I6E (SSC30KQ), MI_VENC_CreateChn must be called before MI_SYS_BindChnPort2, otherwise dmesg shows the channel is not created and bind errors. (消息 1)
• (Infinity6E family) H.265 slice split (MI_VENC_SetH265SliceSplit, u32SliceRowCount 16) is in Tino's working code on Pudding/I6E. In 2024-01 he thought slicing could be enabled in Majestic with a couple of lines via the new public plugin API. (消息 1, 消息 2)
• (Infinity6E family) Some things cannot be done from a Majestic plugin: e.g. slice mode only works if the VENC is initialised in frame mode or similar, and an already built pipeline cannot be touched. (消息 1)
• (Infinity6E family) The SigmaStar encoder's intra-refresh mode emits no SEI NAL units (a NAL dump shows only IDR, PPS, SPS, TRAIL_N/R and VPS), and Tino has found no sign it can do SEI recovery points/GDR; arbitrary SEI can be injected with MI_VENC_InsertUserData. (消息 1, 消息 2)
• (Infinity6E family) Tino suggests the SigmaStar hardware encoder does not support B-frames. (消息 1)
• (Infinity6E family) I6E/Pudding chips such as SSC338 support lens distortion correction (LDC) in the VPE, which Tino calls somewhat unique (internal VPE LDC/SCL). As he recalls, on SSC338/Pudding LDC works only in Y, while Maruko and later do X/Y. (消息 1, 消息 2, 消息 3)
• (Infinity6E family) The Pudding VPE has a good, smooth digital zoom (MI_VPE_LoadPortZoomTable / MI_VPE_StartPortZoom), which Tino checked. MI_VPE_SetPortMode can also up-scale, but with risk of FIFO FULL in realtime mode. (消息 1, 消息 2)
• (Infinity6E family) Tino doesn't think downscaling the sensor image (e.g. to 1080p) on I6E needs the CPU; he points to the DIVP hardware block and believes Majestic already uses it. He thinks scaler parameters may be changeable without restarting the pipeline as long as the output SPS/PPS does not change, perhaps using SNR->VIF->VPE->VDIVP->VENC, but says this should be checked. (消息 1, 消息 2)
• (Infinity6E family) Tino thinks Majestic already uses real-time VIF-VPE binding on I6E, and IIRC connecting RGN directly to VPE is possible only on I6E. (消息 1, 消息 2)
• (Infinity6E family) A raw sensor frame can be dumped through the MI VIF procfs, e.g. echo dump 0 0 /tmp > /proc/mi_modules/mi_vif/mi_vif0. For per-module debug logging, /proc/mi_modules/mi_log_info is a better route than UART console messages. (消息 1, 消息 2)
• (Infinity6E family) For an OSD on SigmaStar you need to draw TTF text onto an ARGB1555 surface. The VDF module has CCTV-related APIs for MD/OD/VG (motion detection, occlusion detection, virtual gate), and the Pudding IVE has an image shift detector. (消息 1, 消息 2, 消息 3)
• (Infinity6E family) UVC (USB camera) support for I6x is documented in the Pudding (SSC9381G/9351) docs; I2M is the NVR family, not the I6x camera family. (消息 1)
• (Infinity6E family) OpenIPC's sigmastar-osdrv-infinity6e package includes kernel modules such as mi_ipu.ko and mi_gyro.ko. It looks like mi_gyro.ko supports only ICG-20660, ICG-20330 and ICM-40607 IMUs out of the box, over I2C (default) or SPI, with CCTV-style EIS. (消息 1, 消息 2)
• (Infinity6E family) On I6E the mhal is monolithic and almost as big as the Linux kernel. (消息 1)
• (Infinity6E family) SigmaStar IQ files from different SDK versions are usually incompatible, let alone across families such as I6E vs I6C. (消息 1)
• (Infinity6E family) As of 2024-05-07, mini-i6e and mini-i6c were in progress at the same time. (消息 1)
• (Infinity6E family) As of 2026-06, Tino said Anjoy is already mostly switching to the SSC37x series even for the low end (SSC373), and that once Anjoy runs out of its old SSC338Q/30KD/30KQ stock 'we'll find out right away'. His impression is that few modules still use SSC338/30KD/30KQ and no new ones are made; new ones are mainly SSC377/378/373/375/38x. (消息 1, 消息 2)