[gstreamer] Received error from camera daemon....exiting....

I use gstreamer for video capture and encoding, and video decoding, and sometimes, the following information will be printed, and then I can not get es data from the pipeline.

0:02:14.898969479  6182   0x7f501f4a80 WARN                 v4l2src gstv4l2src.c:829:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 34 - ts: 0:02:14.782978959
Socket read error. Camera Daemon stopped functioning.....
Received error from camera daemon....exiting....

When the problem occurs, cpu occupancy rate close to 100%, and then can not capture the encoded data, it came down

RAM 1232/3995MB (lfb 569x4MB) cpu [45%,39%,37%,39%]@614 GR3D 0%@76 EDP limit 0
RAM 1233/3995MB (lfb 569x4MB) cpu [53%,48%,49%,44%]@1036 GR3D 0%@76 EDP limit 0
RAM 1233/3995MB (lfb 569x4MB) cpu [47%,38%,36%,35%]@710 GR3D 0%@76 EDP limit 0
RAM 1233/3995MB (lfb 569x4MB) cpu [43%,49%,40%,44%]@1734 GR3D 0%@76 EDP limit 0
RAM 1233/3995MB (lfb 569x4MB) cpu [52%,42%,34%,27%]@1036 GR3D 0%@76 EDP limit 0
RAM 1233/3995MB (lfb 569x4MB) cpu [48%,36%,31%,36%]@1734 GR3D 0%@76 EDP limit 0
RAM 1233/3995MB (lfb 569x4MB) cpu [96%,96%,96%,96%]@1734 GR3D 0%@76 EDP limit 0
RAM 1237/3995MB (lfb 569x4MB) cpu [96%,95%,96%,95%]@1734 GR3D 0%@76 EDP limit 0
RAM 1237/3995MB (lfb 569x4MB) cpu [96%,95%,97%,96%]@1734 GR3D 0%@76 EDP limit 0
RAM 1238/3995MB (lfb 569x4MB) cpu [96%,94%,95%,97%]@1734 GR3D 0%@76 EDP limit 0
RAM 1240/3995MB (lfb 569x4MB) cpu [95%,95%,94%,96%]@1734 GR3D 0%@76 EDP limit 0
RAM 1241/3995MB (lfb 569x4MB) cpu [96%,96%,95%,94%]@1734 GR3D 0%@76 EDP limit 0
RAM 1242/3995MB (lfb 569x4MB) cpu [96%,94%,95%,94%]@1734 GR3D 0%@76 EDP limit 0
RAM 1246/3995MB (lfb 569x4MB) cpu [96%,96%,95%,95%]@1734 GR3D 0%@76 EDP limit 0
RAM 1248/3995MB (lfb 569x4MB) cpu [37%,30%,30%,37%]@614 GR3D 0%@76 EDP limit 0
RAM 1249/3995MB (lfb 569x4MB) cpu [55%,44%,48%,38%]@1734 GR3D 0%@76 EDP limit 0

I would like to ask what is the reason, my application will have multi-channel encoding and decoding, the general cpu occupancy rate higher, I found that the higher the occupancy rate of cpu this thing the higher the probability of occurrence, the following is my coding part Code

descr = g_strdup_printf ("nvcamerasrc ! \
video/x-raw(memory:NVMM), width=3840, height=2160, format=I420, framerate=25/1 ! \
nvvidconv flip-method=2 ! video/x-raw(memory:NVMM), width=3840, height=2160, format=I420, framerate=25/1 ! \
tee name=t ! \
queue ! omxh265enc bitrate=6000000 name=encoder ! video/x-h265, stream-format=byte-stream ! fakesink name=ipcsink \
t. ! \
queue ! nvvidconv ! video/x-raw(memory:NVMM), format=I420, width=3840, height=2160, framerate=25/1 ! nvvidconv ! video/x-raw ! fakesink name=yuvsink");

pipeline = gst_parse_launch (descr, &error);


/* get es sink */
ipcsink = gst_bin_get_by_name (GST_BIN (pipeline), "ipcsink");
g_object_set (G_OBJECT (ipcsink), "signal-handoffs", TRUE, NULL);
g_object_set (G_OBJECT (ipcsink), "can-activate-pull", TRUE,  NULL);
g_signal_connect (ipcsink, "handoff", G_CALLBACK (get_es), obj->ipc_out_es);


/* get yuv sink */
yuvsink = gst_bin_get_by_name (GST_BIN (pipeline), "yuvsink");
g_object_set (G_OBJECT (yuvsink), "enable-last-sample", TRUE,  NULL);


/* get encoder handle */
encoder = gst_bin_get_by_name (GST_BIN (pipeline), "encoder");
g_object_set(G_OBJECT(encoder), "control-rate", 2,NULL);  //constant
g_object_set(G_OBJECT(encoder), "iframeinterval", params_inside->gop_len, NULL);

if (params_inside->enc_reso == ENCODE_RESO_4K)
	g_object_set(G_OBJECT(encoder), "quality-level", 0,NULL);//base level
else
	g_object_set(G_OBJECT(encoder), "quality-level", 2,NULL);//high level

if (gst_element_set_state(pipeline, GST_STATE_PLAYING) == GST_STATE_CHANGE_FAILURE) 
{  
	gst_object_unref (pipeline); 
	return -1;
}

Hi Li,
How long does it take to reproduce the issue? Can we reproduce the same with onboard ov5693?

Hi DaneLLL,

About 15 minutes, sometimes more quickly appear.
I am trying to write a small demo to reproduce the problem.