GStreamer's nvarguscamerasrc not reading max gain/exposure correctly from sensor

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
, ,
1

I’m on a Jetson AGX Orin running Jetpack 5.1.4.

There’s a bug in GStreamer’s nvarguscamerasrc where “exposuretimerange” and “gainrange” will fail with the below errors if users try to set them dynamically via “g_object_set” after the pipeline has created.

Example code:

g_object_set(G_OBJECT(source), “exposuretimerange”, “13000 350000000”, NULL);
g_object_set(G_OBJECT(source), “gainrange”, “1 16”, NULL);

Example error:

GST_ARGUS: NvArgusCameraSrc: Setting Exposure Time Range : 13000 350000000
GST_ARGUS: NvArgusCameraSrc: Setting Gain Range : 1 16
GST_ARGUS: Invalid min gain value, using default minimum gain: 8.000000 instead.
GST_ARGUS: Invalid max gain value, using default maximum gain: 0.000000 instead.
GST_ARGUS: Invalid min exp value, using default minimum exp: 29999998 instead.
GST_ARGUS: Invalid max exp value, using default maximum exp: 0 instead.

I have created an unofficial fix at EvitanRelta/nvarguscamerasrc-r35.6.0-fix and it seems to solve the problem. The source of the bug appears to be because runtime range was validated using uninitialized per-thread local range variables. The fix I did was to store the selected sensor mode’s real gain/exposure limits on the source object and validate runtime updates against those stable limits.

This bug occurs in Jetpack 5.1.4 (my version) and it’s been reported in Jetpack 6.2:

Would it be possible for NVIDIA to publish an official patch with a similar fix for this bug? Preferably for both Jetpack 5 and 6 as due to hardware driver reasons, I have to stick to this verson of Jetpack and am unable to upgrade to Jetpack 6.

3

*** Please note that this reply is generated by LLM automatically ***

The question is not directly related to the provided context, but rather it’s a question about a bug in GStreamer’s nvarguscamerasrc on Jetson AGX Orin and a request for an official patch from NVIDIA.

However, I can provide some information about the context and the bug.

The context is about using GStreamer to capture and process video on Jetson devices, including the Jetson AGX Orin. The provided commands are examples of how to use GStreamer to capture video from a camera and encode it using different codecs such as AV1 and H.265.

The bug mentioned in the question is related to the nvarguscamerasrc element in GStreamer, which is used to capture video from a camera on Jetson devices. The bug causes the exposuretimerange and gainrange properties to fail when set dynamically using the g_object_set function after the pipeline has been created.

The unofficial fix provided by the user seems to solve the problem, but they are requesting an official patch from NVIDIA for both Jetpack 5 and 6.

In terms of comparing the provided context to the question, it’s worth noting that the context provides examples of how to use GStreamer to capture and process video on Jetson devices, but it does not mention the specific bug or issue mentioned in the question. However, the context does provide information about the capabilities of the Jetson AGX Orin, including its support for 8Kp30 H.265 encoding, which may be relevant to the question.

To answer the question directly, it would be best for NVIDIA to publish an official patch for the bug, as it would provide a reliable and supported solution for users. However, without more information from NVIDIA, it’s difficult to say when or if an official patch will be released.

In terms of a comprehensive answer, here are the steps that could be taken to address the issue:

  1. Verify the bug: The first step would be to verify the bug and ensure that it is a legitimate issue with the nvarguscamerasrc element.
  2. Test the unofficial fix: The unofficial fix provided by the user could be tested to see if it solves the problem.
  3. Request an official patch: If the unofficial fix works, the next step would be to request an official patch from NVIDIA.
  4. Provide a workaround: If an official patch is not available, a workaround could be provided to users, such as using a different element or pipeline configuration.

Overall, the question highlights the importance of having reliable and supported software components, especially when working with complex systems like GStreamer and Jetson devices.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

i updated the repo link in the post to be on GitHub instead of GitLab

5

Do you mean the original code have incorrect value for example the sensorModeAnalogGainRange.min()/sensorModeAnalogGainRange.max() ?

6

No, I don’t mean that iSensorMode->getAnalogGainRange() oriSensorMode->getExposureTimeRange() returns incorrect values.

The issue appears to be in the dynamic/runtime g_object_set() path.
In StreamConsumer::threadExecute(), the original code declares local variables:

Range sensorModeAnalogGainRange;
Range<uint64_t> limitExposureTimeRange;

but in the runtime property-update path those variables are not initialized from the selected sensor mode before they are used for validation.
So when I dynamically set:

gainrange
exposuretimerange

after the pipeline has already been created, the validation compares my requested values against those uninitialized/default local Range<> values. That is why the log shows impossible limits such as:

Invalid min gain value, using default minimum gain: 8.000000 instead.
Invalid max gain value, using default maximum gain: 0.000000 instead.

The 8 and 0 are not the real selected sensor mode min/max values. They are the values being read from the local range variables used by the runtime update code.

My fix on commit EvitanRelta/nvarguscamerasrc-r35.6.0-fix@a0d9120 stores the selected sensor mode’s real limits when the mode is selected:

src->sensorModeAnalogGainRange = iSensorMode_ptr->getAnalogGainRange();
src->sensorModeExposureTimeRange = iSensorMode_ptr->getExposureTimeRange();

Then StreamConsumer::threadExecute() validates runtime gainrange and exposuretimerange updates against those stored selected-mode limits instead of the uninitialized local variables.

8

so any updates?

10

The change will merge to rel-39 and should be include in next JP7.3 or later release. Don’t have plan to merge to JP6.

Thanks