1

We have a system where I launch 6 gstreamer pipelines for 6 cameras with nvarguscamerasrc. The pipleines are started programmatically in a loop.

This was working with R32.4.3, but with R32.5.0, only 5 out of the 6 pipelines start correctly.

The following errors are output on stdout/stderr:

nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
nvbuf_utils: Can not get HW buffer from FD… Exiting…

This can be reproduced with a simple example from the command line:

gst-launch-1.0
nvarguscamerasrc sensor-id=0 ! ‘video/x-raw(memory:NVMM),format=(string)NV12’ ! fakesink
nvarguscamerasrc sensor-id=1 ! ‘video/x-raw(memory:NVMM),format=(string)NV12’ ! fakesink
nvarguscamerasrc sensor-id=2 ! ‘video/x-raw(memory:NVMM),format=(string)NV12’ ! fakesink
nvarguscamerasrc sensor-id=3 ! ‘video/x-raw(memory:NVMM),format=(string)NV12’ ! fakesink
nvarguscamerasrc sensor-id=4 ! ‘video/x-raw(memory:NVMM),format=(string)NV12’ ! fakesink
nvarguscamerasrc sensor-id=5 ! ‘video/x-raw(memory:NVMM),format=(string)NV12’ ! fakesink

Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
nvbuf_utils: Can not get HW buffer from FD… Exiting…
ERROR: from element /GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc3: TIMEOUT
Additional debug info:
Argus Error Status
Execution ended after 0:00:01.967467680
Setting pipeline to PAUSED …
Setting pipeline to READY …
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
nvbuf_utils: Can not get HW buffer from FD… Exiting…
Setting pipeline to NULL …
Freeing pipeline …

We have found that inserting a one-second delay between starting each pipeline can work-around the problem, but adds additional start-up latency for our product. Also, without knowing the root cause, it is hard to have confidence in a “delay work-around.”

Is this a known issue? Are there new timing requirements in R32.5 for starting nvarguscamerasrc pipelines?

1 Like
3

Could you try enable infinite timeout. Enable it before launch camera by gst-launch.

sudo service nvargus-daemon stop
sudo enableCamInfiniteTimeout=1 nvargus-daemon
4

Hi ShaneCCC, thanks for the advice. I am trying to check it, but do not run a full Ubuntu system and do not have “system”. I have tried the following:

/etc/init.d/nvargus-daemon stop
enableCamInfiniteTimeout=1 /etc/init.d/nvargus-daemon start

However, I see no difference in behavior.

Did the value “enableCamInfiniteTimeout” default to 1 previously in R32.4.3 and now change?

Is there any negative side-effect to having “Infinite” timeout?

5

It’s for debug mode only.

6

Hi ShaneCCC, do you mean that we should not use enableCamInfiniteTimeout=1 for a production system, only for debugging?

We will need a solution for a production 6 camera system.

7

Have try to replace the /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvarguscamerasrc.so by attached file and reboot the system to try.

libgstnvarguscamerasrc.so.incr_time (79.2 KB)

8

Hi ShaneCCC, Thank you for the response. I can confirm that libgstnvarguscamerasrc.so.incr_time did solve the problem in my initial testing. I see there is some additional debug messages and that starting each pipeline now takes a second.

Is the only change adding a delay inside the plugin? Or are there other changes as well?

9

Just increase the timeout time only.

11

Hi @ShaneCCC ,

Is it possible to obtained the patch of this fix to apply it to gst-nvarguscamerasrc sources that are provided within Jetpack Sources?

Currently I am facing the same error, but I am working on a modified version of gst-nvarguscamerasrc because I need some log I am adding, therefore the .so version does not work for me.

Thanks.

12

I just modify below define in the file header.

static const uint64_t WAIT_FOR_EVENT_TIMEOUT  = 3000000000;
static const uint64_t ACQUIRE_FRAME_TIMEOUT   = 5000000000;
1 Like