What do these parameters actually do?
So does do-timestamp=true use NV specific calls into libargus to set the buf.pts (presentation timestamp) on each GstBuf or does it attach a GstMeta to it (I can’t find one though)?
Same with enable-meta=true…where is this information available in a Gst pipeline?
Thanks!
See that for some clues. Eee gad!
CarlosR92 had shared his experience in Nvarguscamerasrc Buffer Metadata is missing - Jetson TX2 - NVIDIA Developer Forums
DameLL this should all be documented. It’s kinda insane how Python programmers are suppose to get the frame numbers and timestamps from the enable-metadata attribute by de-referencing a C-style gpointer in Python…
Hi,
We have most samples in C/C++. It may not be friendly for Python as you have experienced. We will evaluate and check if gstreamer and tegra_multimedia_api can support Python.
It would be great if you can share test code and steps to show ‘de-referencing a C-style gpointer in Python’. so that we can reproduce it and check if we can have better design for nvarguscamerasrc.
You absolutely can. You should be creating GstMeta’s for each GstBuf and the meta object should be well defined in the doc.
Read the link above in comment #2. I have the steps. It seems to work. Can you please also answer my question on what is “sensor_data” pointing to in this context?
I’d also like to know if on 28.2.1 what’s up with “frame_num” not being continuous? I’d say I’m dropping frames but that doesn’t make sense given my buffering and the fact that I’m seeing the correct number of frames per interval???
One final EDIT: For me to use nvarguscamerasrc I need to be able to turn off AE and have aelock or turn on AE PLUS I need to be able to access more than one sensor with it using sensor_id equivalent AND fix it to 30fps. The gst-inspect-1.0 output is woefully incomplete for nvarguscamerasrc if it supports these things.
Hi,
sensor_data is not public.
We don’t observe it with default camera ov5693. In your case, frame_num is not continuous but timestamp is in expected interval( 33ms, or 16ms )?
I’m using Leopard Imaging IMX377 and I will see the “frame_num” field be basically continuous with a few gaps here and there (typically a single frame, so like 1,2,3,5,6,7,9,11,13 etc.). It’s pretty consistent and this is with setting the nvcamerasrc queue-size=50.
But the number of frames for the interval is about right! So in my pipeline I have set a ‘max-file-duration’ of ten seconds which at 30fps should be 300 frames. And I basically see that - typically I will capture about 300 (sometimes 299, sometimes 301 etc.).
Any idea?
@alex.sack, your case is interesting, I don’t see that behavior in any of my tests, neither with GStreamer (C/C++) nor LibArgus.
Have you tried to use LibArgus examples to see if the frame numbers come in the same way?
I recommend to use the 09_camera_jpeg_capture example, and use below code to print out the frame number and timestamp:
else if (iNativeBuffer->copyToNvBuffer(m_dmabuf) != STATUS_OK)
{
ORIGINATE_ERROR("Failed to copy frame to NvBuffer.");
}
+ IArgusCaptureMetadata *iArgusCaptureMetadata = interface_cast<IArgusCaptureMetadata>(frame);
+ if (!iArgusCaptureMetadata) {
+ ORIGINATE_ERROR("Failed to get IArgusCaptureMetadata interface.");
+ } else {
+ CaptureMetadata *metadata = iArgusCaptureMetadata->getMetadata();
+ ICaptureMetadata *iMetadata = interface_cast<ICaptureMetadata>(metadata);
+ if (!iMetadata) {
+ ORIGINATE_ERROR("Failed to get ICaptureMetadata interface.");
+ } else {
+ unsigned long long timestamp = 0;
+ timestamp = static_cast<unsigned long long>(iMetadata->getSensorTimestamp());
+ printf ("Frame Number: %lu, Timestamp: %llu\n", iFrame->getNumber(),timestamp);
+ }
+ }
// Process frame.
processV4L2Fd(m_dmabuf, iFrame->getNumber());
}
You can add this part at line 156 of this example. Please take as reference that I’m working on Jetpack 4.2, so if you are using a older Jetpack that application might change a bit. Take that as reference to check if the same issue appears when using LibArgus.
CarlosR92, do you know how I can add Jetpack SDK post flash? The image I have doesn’t have cudart on it making building these examples difficult.
I don’t really want to reflash either right now.
Hi,
You may remove -lcudart in tegra_multimedia_api\samples\Rules.mk. Some samples may fail to build but 09_camera_jpeg_capture should pass.
PRODUCER: [0] W=4104 H=3046
PRODUCER: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
CONSUMER: Producer has connected; continuing.
SCF: Error InvalidState: NonFatal ISO BW requested not set. Requested = 2147483647 Set = 1500000 (in src/services/power/PowerServiceCore.cpp, function setCameraBw(), line 653)
SCF: Error OverFlow: Temp BufferPool exceeds max expected size: 7 (4104x3046 BL U8_V8 420SP) (in src/services/buffermanager/BufferPool.cpp, function allocBuffer(), line 217)
SCF: Error OverFlow: Possibly due to pipeline slowdown, can cause memory bloat. (in src/services/buffermanager/BufferPool.cpp, function allocBuffer(), line 219)
Error generated. main.cpp, threadExecute:162 Failed to get ICaptureMetadata interface.
Error generated. /home/nvidia/Development/tegra_multimedia_api/argus/samples/utils/Thread.cpp, threadFunction:132 (propagating)
Error generated. main.cpp, threadExecute:162 Failed to get ICaptureMetadata interface.
Error generated. /home/nvidia/Development/tegra_multimedia_api/argus/samples/utils/Thread.cpp, threadFunction:132 (propagating)
PRODUCER: Done – exiting.
I’m wondering if this is the ISP driver from Leaopard Imaging causing the issue. Not sure.
I also noticed that frame_num does not get reset sometimes.
For example: If I start a window to set the exposure/gain settings in real time using a simple gstreamer pipeline and then use another gstreamer pipeline to start a new recording - the frame_num starts at some arbitrary large value and increments from there.
Let me talk to Leopard more unless you see something obvious?
Hi @alex.sack,
I can see similar issues but the app works and the timestamps and frame_num are printed out properly. Not sure why the frame_num behaves like that for you. Further debugging might be needed.
Yeah, I’ve contacted the vendor as well. I can’t really explain it. I just can’t get continuous frame numbers. It’s honestly not a big deal if the number of frames are correct, i.e. not dropping.