Persistent OOM (Status 10) for 1x 8MP Sensor in Custom SIPL App vs. 4x 8MP Success in Official Sample (DRIVE OS 6.0.10)

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

8MP/30FPS Streaming Failures on Production Orin: Custom SIPL OOM (Status 10) and DriveWorks Serializer “Not Supported” (DRIVE OS 6.0.10)

Environment:

  • Hardware: DRIVE AGX Orin P3710-0010

  • OS: DRIVE OS 6.0.10 (Linux 5.15.122-rt-tegra)

  • CMA Memory: Total 256 MB (CmaTotal: 262144 kB)

  • Sensors: Valeo 8MP (IMX728)

The Core Contradiction:

  • Official Sample Success: nvsipl_camera -p V1SIM728S3RU4070HC00_CPHY_x4 works perfectly with four 8MP sensors active simultaneously in the 256MB CMA pool.

  • Custom Path Failures: Every attempt to implement a custom streaming or encoding pipeline for even one 8MP sensor has failed.

Path 1: The DriveWorks “Dead End”

I initially attempted to use the DriveWorks dwImageSerializer and dwSensorSerializer APIs to stream H.265/RTP, but hit an immediate roadblock:

  • dwSensorSerializer: Returns DW_INVALID_ARGUMENT. Internal logs explicitly state: “StreamSink type is not supported” for type=rtp.

  • dwImageSerializer: Previously tested and failed to initialize for RTP/H.265 on this production build.

  • Result: DriveWorks appears to have restricted RTP sink support on this specific production kernel/hardware combination.

Path 2: The SIPL/NvMedia OOM (Status 10)

Moving to a lower-level SIPL implementation to bypass DriveWorks restrictions resulted in persistent memory allocation failures:

  • Failure: CImageManager::Allocate returns NVSIPL_STATUS_OUT_OF_MEMORY (Status 10) during NvSciBufObjAlloc.

  • Minimized Setup: This occurs even with only 1 sensor enabled, ISP_IMAGE_POOL_SIZE reduced to 2U, and usage flags set to 0x40ULL (SIPL only).

  • Observation: Despite meminfo showing ~200MB of CmaFree, the allocation for a single 8MP buffer (~12.5MB) fails.

Current Configuration (Minimized for Testing):

  • Usage Flags: Set to 0x40ULL (SIPL only). Video Encoder flags (0x04) have been removed to isolate the issue.

  • Buffer Count: ISP_IMAGE_POOL_SIZE reduced to 2U.

  • Sensor Mask: uLinkMask = 0x0001 (Only Link 0 enabled).

  • Display: Disabled (no -d flag) to prevent WFD buffer allocation.

  • System State: GDM stopped, ISP/VI clocks maxed, and /dev/shm/nvsci* cleared.

Technical Observations:

The failure occurs during the NvSciBufObjAlloc step immediately following GetImageAttributes and NvSciBufAttrListReconcile.

  • Calculated Memory: 1 sensor $\times$ 2 buffers $\times$ 12.5 MB $\approx$ 25 MB.

  • Available Memory: CmaFree reported at ~200 MB.

  • Despite having 8x the required memory available, the allocation fails with Status 10.

Questions for NVIDIA Engineers:

  1. CMA Architecture: Why can the official nvsipl_camera sample allocate buffers for 4x 8MP sensors (~16+ buffers total) while a custom app fails to allocate for 2 buffers on a single sensor?

  2. API Restrictions: Is the rtp StreamSink for DriveWorks serializers intentionally disabled or unsupported on the P3710-0010 build?

  3. Memory Alignment: Does the production kernel enforce stricter alignment or contiguous requirements for 8MP (3840x2160) NvSciBuf objects that differ from the official samples?

  4. ISP Scratchpad: Does the 8MP platform configuration reserve a large “internal” chunk of CMA that is not accounted for in the user-defined pool size, leading to these OOMs?

    1. log.txt (120.8 KB)
5

Dear @anusha.manila ,

Are you using DRIVE AGX Orin devkit or any other board based based on Orin? Note that Devkit (and DevZone releases )not for production.
Do you have any other support channel?

6

I am using the P3710-0010 Developer Kit reference hardware, and I am running the DRIVE OS 6.0.10 Linux SDK. I don’t have any other support channel. I want to verify if this 8MP OOM is a known behavior in the 6.0.10 SIPL framework.

7

type=user or disk is supported as mentioned at DriveWorks SDK Reference: Sensor Serializer
have you used type=rtp in the old release and working?

Does that mean your application developed using NvSIPL APIs failed to capture data using 2 cameras?

Could you share what is the use case you want to achieve? Is it encode the camera stream on orin and send to another host via network?

8

I figured out the solution via DriveWorks. So we can close this topic, no more pursuing nvsipl.

9

Dear @anusha.manila ,
Could you please share your approach to help others in the community

10

I used Driveworks to deliver H264 Elemental packets and then use an RTP lib (live555) to packetize them and send them over Ethernet.