Jumps in capture with unstable setup

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
,
1

Hi,
We are on a serdes setup with imx219 sensors that is unstable, there seems to be signal integrity or other HW issues on our setup. We observed that in some cases those issues cause the following behavior during capture:

The following pipeline was used:

 gst-launch-1.0 nvarguscamerasrc sensor-id=1 ! "video/x-raw(memory:NVMM),width=(int)1640, height=(int)1232, framerate=(fraction)15/1"! nvv4l2h264enc ! h264parse ! qtmux ! filesink location=c0.mp4 -ve

We also tried SW encoding and direct frame read with appsink, in both cases we get the same results.
Is there a way to avoid getting those jumps back in time? or the way the video frames and buffers are populated is coupled to the argus/isp stack?

I know the HW and signal issues are at fault, but is there a software way we can at least avoid those jumps backwards?

Our setup is:

  • Xavier NX
  • JP5.1.4
  • ub960 with ub953
  • imx219

Regards,
Andres
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com

3

hello andres.artavia,

could you please analysis the frame index and also the timestamp during the frames jumping backwards?

4

Hi,
The following can be observed:

CONSUMER: n: 64, ts: 18446744061124362496 
CONSUMER: n: 65, ts: 350637103880 
CONSUMER: n: 66, ts: 18446744061124362496 
CONSUMER: n: 67, ts: 18446744061124362496 
CONSUMER: n: 68, ts: 350770410880 
CONSUMER: n: 69, ts: 350803737880 
CONSUMER: n: 70, ts: 350837064880 
CONSUMER: n: 71, ts: 350870390880 
CONSUMER: n: 72, ts: 350903717880 
CONSUMER: n: 73, ts: 350937044880 
CONSUMER: n: 74, ts: 350970371880 
CONSUMER: n: 75, ts: 351003698880

Those jumps to 18446744061124362496, doesn’t look right and seem to be the same value always, might be a way to detect the jumps. Also we were already getting the VI timestamp and adding it to the gstbuffer, so that’s why it might look different than a normal gstreamer ts.
Thanks for the suggestion, attaching the logs and the code change for reference.

Regards,
Andres

diff_gst.txt (1.3 KB)
log_ts.log (20.8 KB)

5

ya, you may try avoiding sending those abnormal frames to consumer.

7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.