[RTL8735B / AmebaPro2] SC231HAI Sensor Support: Missing iq_sc231h.bin, WDR/HDR Capability, and Hardware Reference Design

[Pammy]

Hi @Hsu_Shawn,

I have edited the previous message and added the answer for [6.1].

[6.1] Error code

@Hsu_Shawn

• What is the exact meaning of ret=0x98600800 (group=3, “Driver”)? video_get_error_group() extracts the group as error_id >> 27 & 0xF, but we do not have the mapping table for error IDs.

ret=0x98600800 indicates that video_open() failed at the driver layer. This return value corresponds to the ERR_ID_DRV_VIDEO_INVALID_CROP_SIZE error.

However, we are unable to share the mapping table at this time as it contains confidential information. If you encounter any similar errors in the future, feel free to let us know, and we will be happy to assist you in identifying the issue.

@Hsu_Shawn

• For VOE command 0x206 fail ret 0xff — is there a defined meaning for return value 0xff under 0x206 (VOE_OPEN_CMD)?

VOE_OPEN_CMD does more than just open a handle. It asks the VOE firmware side to set up and start the entire video stream, including the sensor, ISP, encoder, and stream buffers. If any part of that setup fails, VOE returns 0xff.
Some common reasons:

1. Channel already open — the engine refuses to create a stream on a channel that’s already running.
2. The codec, resolution, FPS, or stream format combination is not supported. For example, the requested H264/JPEG/YUV combination may not work with the selected sensor.
3. Sensor/ISP not ready at open — The sensor may have failed to initialize, have an I2C/IQ/FCS problem, or already be used by another feature such as USB UVC.
4. VOE engine not properly booted / firmware mismatch — The VOE engine may not have booted correctly.
5. Not enough memory for the encoder/stream buffers in the VOE heap.

@Hsu_Shawn

Two questions this raises for us, if the team can comment:

1. With video_voe_presetting_by_params() recalculating the heap, is the 1920×1080 MJPEG limitation in the JPEG buffer specifically, or in the total VOE heap? The VOE CH0 JPG buff full (queue/used/out/rsvd) 19/128KB message you saw suggests the former.
2. Is there a supported way to reserve the FHD-sized JPEG buffer at boot and keep it across a runtime codec switch, even at the cost of that memory being held while H.264/H.265 is active? For our product that trade is acceptable — we would rather lose the memory than lose the resolution.

In the SDK’s default JPEG flow, JPEG is primarily intended for snapshot-type usage rather than continuous streaming. The JPEG path keeps a buffer roughly corresponding to one NV12 frame at the configured resolution. If the JPEG callback holds the buffer for too long—for example, while writing the image to storage—the JPEG buffer can become full.

The JPEG buffer-full condition can also be improved by:

• increasing the JPEG buffer size, or
• lowering the JPEG quality level (qlevel) to reduce the encoded frame size.

If continuous MJPEG streaming is required, a queue-based mechanism similar to the H.264 path may be more appropriate. But for this particular JPEG streaming flow has not been extensively validated.

The maximum achievable frame rate would also ultimately be limited by the sensor’s supported FPS.

At this point, we do not have confirmation of an officially supported SDK mechanism that reserves an FHD-sized JPEG buffer at boot and guarantees that the same allocation is retained across runtime H.264/H.265/JPEG codec switches. The current SDK flow recalculates/reconfigures the required memory according to the active video parameters.

@Hsu_Shawn

We reported this on 2026-08-28 (FAE_RTSP_TRANSPORT_INIT_20260828.md) and mention it again only because it is likely to affect other Profile T customers.

Let me look into it and get back to you.