NvMedia’s IPP is a legacy framework that has been deprecated and replaced with SIPL; DriveWorks has updated its Camera Sensor implementation accordingly. DriveWorks automatically translates parameters used with the legacy IPP-based camera.gmsl protocol to those suitable for SIPL. While existing applications involving single camera usage may continue to work out of the box, it is best practice to migrate existing applications to the updated SIPL-based camera.gmsl protocol at your earliest convenience.

Note: If you have existing DriveWorks applications utilizing the IPP framework and are unable to migrate to SIPL, use camera.gmsl.ipp instead of camera.gmsl for your camera protocol.

This short guide showcases the differences and how to update the parameters.

While IPP drivers are opaque and only exposed via DriveWorks as camera-type parameters, the SIPL drivers are highly customizable. A selection of GMSL camera drivers are provided in each release, and are automatically compatible with DriveWorks. The list of supported SIPL drivers in the current platform is viewable by running SIPL Query Tool tool in the DriveWorks tools/sensors folder. The output of the tool prints all camera modules directly from the NvSIPL library and database of the current platform. These camera modules are used to specify the camera in the camera-name parameter within the camera.gmsl protocol.

It is possible to translate IPP's camera-type parameter into SIPL's camera-name. Please refer to the list of mappings below.

IPP camera-type	SIPL camera-name
ar0231-rccb-bae-sf3324	SF3324
ar0231-rccb-bae-sf3325	SF3325
ar0144-cccc-none-gazet1	AR0144P

IPP also maps a dwSensorHandle_t to a port (camera brick), where up to four cameras can be controlled from a single API call with dwSensorCamera_readFrame(). This also involves using siblingIndex to distinguish between the four cameras in the brick.

For SIPL, each camera is mapped to an individual dwSensorHandle_t. This means that mapping IPP's parameter camera-mask is not possible, unless the mask only has 1 camera specified: 0001, 0010, 0100, or 1000. The SIPL parameter instead requires link to specify the camera ID in a port to enable.

Previously, the parameter camera-group was used to simplify port selection by calling each camera group: A, B, C, or D. In SIPL this is not valid anymore. Instead, use csi-port (specified in the DRIVE OS documentation) with the changes based on the camera model and use case. Examples include: csi-a, csi-c, cs-cd, trio-ab etc.

Note: camera-group=b does not correspond to csi-port=csi-b. It corresponds to csi-port=csi-c, csi-port=csi-cd, or csi-port=trio-cd.

Lastly, there are changes to the APIs. When using camera.gmsl, all cameras must be created before any call to dwSensor_start. Afterwards, no change in the sensor setup can be made.

Regarding camera.virtual protocol, all raw videos that have a file version older than V6 will no longer use SIPL due to incompatibility issues. These videos should not be used anymore, and newer videos should be adopted or recorded. All other videos will automatically use NvSIPL.