How can i analyse data from NvSciBufObjGetConstCpuPtr

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Continuing the discussion from NvSciBufObjGetPixels is too slow to get yuv420 frames by 30fps:

Please provide the following info (tick the boxes after creating this topic):
Software Version
DRIVE OS 6.0.8.1
[yes] DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
[yes] DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
1.9.3.10904
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
[yes] native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

Hi there, i also found that NVSCIBufObjGetPixels is too slow to get ISP0/1/2 frames… so i tried to use NVSCIBufObjGetPixels to get VA addr and dump this buf. As a result, I’ve noticed that I can’t play this yuv image correctly, so I’m wondering how the data is aligned.
my setting:
sensor input is raw12:height:2168, width:3840, embedded_top =4 ,embedded_bottom=4,
ICP Buf :output align height: 2168 ,output height: 2168, output width: 3840, output pitch: 7680,output BPP: 16
ISP0 Buf:height:2160, width:3840, output align height: 2176, output height: 2160, output width: 3840, output pitch: 3840, output padding: top 0, bottom 0,output BPP: 8,
numbersuface[0]:width:3840, height:2160, align_height:2176, xScalePtr:1, yScalePtr:1, bytesPerPixelPtr:1,align_size:8355840, pBuffPitches0:3840
numbersuface[1]:width:3840, height:2160, align_height:2176, xScalePtr:0.5, yScalePtr:0.5, bytesPerPixelPtr:1,align_size:2088960, pBuffPitches1:1920
numbersuface[2]:width:3840, height:2160, align_height:2176, xScalePtr:0.5, yScalePtr:0.5, bytesPerPixelPtr:1,align_size:2088960, pBuffPitches2:1920

      //ISP0 Buf:image_ptr
      void const *image_ptr = nullptr;
      sciErr = NvSciBufObjGetConstCpuPtr(bufPtr, &image_ptr);
      CHK_NVSCISTATUS_AND_RETURN(sciErr, "NvSciBufObjGetConstCpuPtr Failed");
      uint8_t *nvbuf_image_ptr =
          reinterpret_cast<uint8_t *>(const_cast<void *>(image_ptr));
        align_size[0] = (width * xScalePtr[0] * align_height * yScalePtr[0] *
                         bytesPerPixelPtr[0]); //3840×2176=8355840
       fwrite(nvbuf_image_ptr, 1, align_size[0], m_pOutFile); //align_size[0] =8355840


but when i dump  Y part which  size is  8355840 , i got a disordered image， so i want to know if my method is correct? if not, what's the correct method to get a yuv image? Thanks!

isp_yuv.yuv.txt (8.0 MB)

2

additions: i’m using linux and i can dump the correct image with NvSciBufObjGetPixels, so i believe there must be some process about image in this api, how can i implement it through buf VA addr got by NvSciBufObjGetConstCpuPtr … Thanks

4

Dear @asuka.sh,
May I know your complete use case details? You want YUV output to store to a file? Is it possible to share full code snippet and camera module details

5

Hi Dear,
Yes, I want YUV output to store to a file but it takes about 100ms if i use NVSCIBufObjGetPixels which is too slow for me . my camera module is onSemi AR0823.
you can check my mainly code here, which is based on nvsipl_sample.
nv_test.tar.gz (15.7 KB)
i also found the rules between these two methods:
16 bytes is a pack,I don’t know why the order of the isp is so different and it’s a pain for me to deal with, can you help me? Thank you

image
image1381×894 95.3 KB

6

I’d like to be able to store data continuously, the frame rate is currently 30fps so I’d like to be able to process it in 30ms

7

Dear @asuka.sh,
Just checking if you have used nvsipl_camera to store yuv output from ISP?

8

Dear @SivaRamaKrishnaNV
Yes, i used a function from ccwriter.hpp, you can check the code i sent

9

Hi, @SivaRamaKrishnaNV
Have you checked this?Please contact me if you have any doubts about it.

10

Could you share the file size of 30 frames(or few frames) and disk write speed using dd command ?
If just storing is the actual use case, why there is time limit. Do you see any frame drop notifications?

11

HI @SivaRamaKrishnaNV
yes, there’s some drop notifications, there’s no time limit, but i want the continue frames. 30 frames’s size is 12441600 *30. i don’t think it’s a problem of disk write speed. the time gap between NVSCIBufObjGetPixels and NvSciBufObjGetConstCpuPtr is too big.
I found that ICP pipeline’s NvSciBufImageAttrKey_Layout is PITCH but ISP0’s NvSciBufImageAttrKey_Layout is BLOCK. Maybe that’s the reason why ISP pipeline should take more time to do a format recovery during NVSCIBufObjGetPixels.

12

Could you clarify how this number came? Is it like you stored a frame and checked the file size? Is it in bytes? Also, please provide the disk write speed with dd command. I will check on layout conversion and update you.

13

yes ,it’s in bytes,12441600 = 3840 * 2160 * 1.5(yuv420) , and i think it’s not a latency problem about disk write speed, but a latency in NVSCIBufObjGetPixels.

dev@tegra-ubuntu:~$ time dd if=/dev/zero of=test.img bs=1M count=1024 conv=fdatasync 
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.2829 s, 470 MB/s

real	0m2.390s
user	0m0.000s
sys	0m1.188s
14

The code flow for Block linear and pitch linear is different and it is possible that block linear layout may take more time. I don’t have perf numbers.

So you tried using nvsipl_camera sample with -f flag to store ISP output as YUV and notice frame drop and hence you are exploring other methods to store YUV? Did you check enabling only ISP0 and test using -r 5to see if the file size matches to calculations (150 frames * YUV frame size)

Also, Is the suggestion at NvSciBufObjGetPixels is too slow to get yuv420 frames by 30fps - #6 by SivaRamaKrishnaNV does not work for your case?

16

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