Multiple capture and vp8 encoding gets stucked.

[ACervantes]

Hi all,

I am working on GStreamer application in JetPack 4.2.2 using three cameras for capturing. I am seeing that the cameras eventually gets stucked. I was able to reproduce the issue but with gst-launch pipelines:

gst-launch-1.0 nvarguscamerasrc sensor-id=0 maxperf=1 ! "video/x-raw(memory:NVMM),width=(int)1920,height=(int)1080,format=(string)NV12,framerate=(fraction)30/1" ! perf ! queue ! nvv4l2vp8enc maxperf-enable=1 ! queue ! fakesink
gst-launch-1.0 nvarguscamerasrc sensor-id=1 maxperf=1 ! "video/x-raw(memory:NVMM),width=(int)1920,height=(int)1080,format=(string)NV12,framerate=(fraction)30/1" ! perf ! queue ! nvv4l2vp8enc maxperf-enable=1 ! queue ! fakesink
gst-launch-1.0 nvarguscamerasrc sensor-id=2 maxperf=1 ! "video/x-raw(memory:NVMM),width=(int)1920,height=(int)1080,format=(string)NV12,framerate=(fraction)30/1" ! perf ! queue ! nvv4l2vp8enc maxperf-enable=1 ! queue ! fakesink

I am using the pipelines above, monitoring the pipelines with the perf element https://github.com/RidgeRun/gst-perf.

Basically this is what I have seen from the test I have done so far:

1. I have seen that in one hour running the pipelines I get a camera stucked and it stops sending frames. sometimes two of the three cameras gets stucked and the another one continues sending frames.
2. I did the test with maxperf property set in false, the cameras do not get stucked but the framerate goes down when capturing with the three cameras simultaneously.
3. If I run the three pipelines without encoding and maxperf in true the three cameras works as expected per hours.
4. I also have tested changing the encoder by the omxvp8enc but I see the behavior as 1).

Does any of you have experimented something like 1)?

We had this same system running those pipelines on JetPack 3.2.1 and nvcamerasrc without problems.

Thanks,
-Adrian

[DaneLLL]

Hi,
Please try r32.2.3.

L4T 32.2.3

Jetpack4.2.2 is r32.2.1 and it should not take much effort to upgrade to r32.2.3

We also have Jetpack4.3 released. Would be great if you can try it also, although it may take certain effort to upgrade from r32.2.1.

[ACervantes]

Hi DaneLLL,

After doing some testing, I found what was causing the issue however I do not have a way to solve it.
Basically the issue appears when replacing the nvarguscamerasrc binary with the one you share in this post: https://devtalk.nvidia.com/default/topic/1056918/jetson-tx2/nvarguscamerasrc-buffer-metadata-is-missing-/post/5392925/#5392925

@DaneLLL

Hi,
Please try attachment on r32.2.1. It is verified by adding prob callback to the sample

static GQuark gst_buffer_metadata_quark = 0;
typedef struct AuxBufferData {
  gint64 frame_num;
  gint64 timestamp;
} AuxData;
static GstPadProbeReturn
nvargus_src_pad_buffer_probe (GstPad * pad, GstPadProbeInfo * info,
    gpointer u_data)
{
    AuxData *meta = NULL;
    GstBuffer *buf = (GstBuffer *) info->data;
    gst_buffer_metadata_quark = g_quark_from_static_string ("GstBufferMetaData");
    meta = (AuxData *) gst_mini_object_get_qdata (GST_MINI_OBJECT_CAST (buf),
							   gst_buffer_metadata_quark);

   printf(">>> Gstreamer:Frame #%lu : Timestamp: %lu\n", meta->frame_num, meta->timestamp);
   return GST_PAD_PROBE_OK;
}

GstElement* src = gst_bin_get_by_name(GST_BIN(gst_pipeline), "mysource");
GstPad *src_pad = gst_element_get_static_pad (src, "src");
gst_pad_add_probe (src_pad, GST_PAD_PROBE_TYPE_BUFFER,
    nvargus_src_pad_buffer_probe, NULL, NULL);

Our client was working with nvcamerasrc but now that they moved to JetPack 4.2.2 there is not enable-meta at the nvarguscamerasrc element, that is why we need that binary. If we go back to the default binary that does not have the enable-meta support the pipelines live per days without crashes.

Could you provide some help on this? since we do not have nvarguscamerasrc code is difficult for us to fix this issue.

We appreciate any help provided. Thanks.

-Adrian.

[DaneLLL]

Hi,
The metadata function is in r32.3.1. Do you have plan to move to the version? Or you will stay on r32.2.1?

[ACervantes]

Hi DaneLLL,

Thanks for your help on this. We did some tests in r32.3.1 to check the metadata and it seems to be working. Also we decided to port the driver and test three cameras with JP 4.3, they are working pretty good, We do not see the issue anymore in this new JP.

Thanks so much.

-Adrian