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
hello andres.artavia,
could you please analysis the frame index and also the timestamp during the frames jumping backwards?
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)
ya, you may try avoiding sending those abnormal frames to consumer.