hello, JerryChangModerator
I have an agx orin platform, which uses external stm32 to generate pwm waveform to keep the synchronization of the four lenses. However, during the testing of the two lenses, I found the phenomenon of frame loss. The command and test results are as follows:
GST_DEBUG_DUMP_DOT_DIR=/media/Data/log gst-launch-1.0 nvcompositor name=comp sink_0::xpos=0 sink_0::ypos=0 sink_0::width=960 sink_0::height=540 sink_1::xpos=960 sink_1::ypos=0 sink_1::width=960 sink_1::height=540 ! nvvidconv ! 'video/x-raw(memory:NVMM),width=960,height=1080,format=NV12,framerate=10/1' ! nvv4l2h264enc bitrate=4000000 ! h264parse ! flvmux ! rtmpsink blocksize=24834048 location='rtmp://127.0.0.1/live/mux4' nvarguscamerasrc sensor-id=2 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam0 ! queue ! nvvidconv ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" ! nvvidconv ! "video/x-raw" ! multifilesink max-file-size=1396915200 next-file=4 blocksize=40960 location=cam0_%04d.nv12 -e cam0. ! queue ! comp.sink_0 cam0. ! queue ! nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1' ! nvv4l2h265enc bitrate=7000000 ! h265parse ! mp4mux ! filesink location=cam-0.mp4 nvarguscamerasrc sensor-id=3 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam1 ! queue ! nvvidconv ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" ! nvvidconv ! "video/x-raw" ! multifilesink max-file-size=1396915200 next-file=4 blocksize=40960 location=cam1_%04d.nv12 -e cam1. ! queue ! comp.sink_1 cam1. ! queue ! nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1' ! nvv4l2h265enc bitrate=7000000 ! h265parse ! mp4mux ! filesink location=cam-1.mp4
Acquired Frame: 322, time sec 32 msec 6 id:281470807564768
Acquired Frame: 322, time sec 32 msec 18 id:281470782386656
Acquired Frame: 323, time sec 32 msec 105 id:281470807564768
Acquired Frame: 323, time sec 32 msec 118 id:281470782386656
Acquired Frame: 324, time sec 32 msec 206 id:281470807564768
Acquired Frame: 324, time sec 32 msec 217 id:281470782386656
Acquired Frame: 325, time sec 32 msec 305 id:281470807564768
Acquired Frame: 325, time sec 32 msec 317 id:281470782386656
Acquired Frame: 326, time sec 32 msec 404 id:281470782386656
Acquired Frame: 326, time sec 32 msec 417 id:281470807564768
Acquired Frame: 327, time sec 32 msec 504 id:281470807564768
Acquired Frame: 327, time sec 32 msec 516 id:281470782386656
Acquired Frame: 434, time sec 43 msec 244 id:281470782386656
Acquired Frame: 435, time sec 43 msec 361 id:281470807564768
Acquired Frame: 435, time sec 43 msec 382 id:281470782386656
Acquired Frame: 436, time sec 43 msec 420 id:281470807564768
Acquired Frame: 436, time sec 43 msec 426 id:281470782386656
Acquired Frame: 437, time sec 43 msec 473 id:281470807564768
Acquired Frame: 437, time sec 43 msec 486 id:281470782386656
There is a stable trigger signal during the intermediate pauseThere is a stable trigger signal during the intermediate pause.
gstnvarguscamerasrc.cpp
bool StreamConsumer::threadExecute(GstNvArgusCameraSrc *src)
{
...
//if (!src->silent)
{
guint64 frame_timestamp = iFrame->getTime() - ground_clk;
guint64 millisec_timestamp = ((frame_timestamp % (1000000000)))/1000000;
printf("Acquired Frame: %llu, time sec %llu msec %llu id:%llu\n",
static_cast<unsigned long long>(iFrame->getNumber()),
static_cast<unsigned long long>(frame_timestamp / (1000000000)),
static_cast<unsigned long long>(millisec_timestamp),threadId);
}
...
}
The following is my test of the four-way camera problem MP4, the phenomenon is the same, it is not clear why this situation, CPU/GPU did not run full, and the disk ssd write speed is about 70M, far lower than the maximum write speed supported by ssd.
b7d16a8e25d176e4596df1fde62a2ca3.zip (4.5 MB)