imggrabber segfault

[xannor]

imggrabber seams to segfault, may need to pull the one from allwinner to use instead.

[xannor]

looks like this camera provides /dev/shm/fshare_frame_buf instead of /proc/umap and /proc/mstar.

@roleoroleo would this mean I should pull just the snapshot from allwinner, or would this effect rtsp and onvif as well?

[roleoroleo]

If you can access to /proc/mstar I think it would be better to use it. But if it's not available you can use fshare_frame_buf. Probably you will have to adapt size, header, PPS and SPS header etc...

[xannor]

Given what I understand about the build process now, I am trying an experiment of use the Allwinner as the base and seeing if I can get a solid build. If this works I will then push the imggrabber to the camera and see if that works. From there I will try to rebuild the firmware from the Allwinner (with my mods) and try that. Its starting to look like this camera is literally the same software as the yi-outdoor (it also has the ai human detect) but with sigmastar hardware. (it even physically looks the same as the yi-outdoor and has the same qr code prefix.)

[xannor]

it does not segfault but framefinder cannot find the header, it runs but does not create the index. How did you determine the proper header information?

[roleoroleo]

Dump a copy of the file and try to get h264 nal.

[xannor]

From the memory header, how did you determine that +16 was the dword for the offset? and how did you decide the base offset is 300? my dump file is 16 bytes bigger.

Here is the first 64bytes of my dump (the rest till 316 are all zeros)

00000000  00 00 00 00 05 36 1b 00  1a 45 00 00 40 3c 0c 00  |.....6...E..@<..|
00000010  3b 46 0c 00 38 8c 4c fd  2e 2f 00 00 00 00 00 00  |;F..8.L../......|
00000020  00 00 00 00 09 2d 00 00  00 02 00 00 01 00 00 00  |.....-..........|
00000030  00 00 00 00 9a 11 00 00  00 1d 00 00 00 00 00 00  |................|

and here are a few recent grabs off of the device its self:

/home/app # hexdump -n 64 -vC /dev/shm/fshare_frame_buf
00000000  00 00 00 00 77 3e 1b 00  86 50 03 00 0c 8f 04 00  |....w>...P......|
00000010  95 90 04 00 0f 5c 8f fd  50 6e 04 00 00 00 00 00  |.....\..Pn......|
00000020  00 00 00 00 19 69 04 00  00 02 00 00 01 00 00 00  |.....i..........|
00000030  00 00 00 00 5e 59 01 00  00 1d 00 00 00 00 00 00  |....^Y..........|
00000040
/home/app # hexdump -n 64 -vC /dev/shm/fshare_frame_buf
00000000  00 00 00 00 e7 3f 1b 00  86 50 03 00 4b f6 04 00  |.....?...P..K...|
00000010  64 f6 04 00 b1 60 8f fd  9b 6e 04 00 00 00 00 00  |d....`...n......|
00000020  00 00 00 00 19 69 04 00  00 02 00 00 01 00 00 00  |.....i..........|
00000030  00 00 00 00 5e 59 01 00  00 1d 00 00 00 00 00 00  |....^Y..........|
00000040
/home/app # hexdump -n 64 -vC /dev/shm/fshare_frame_buf
00000000  00 00 00 00 15 12 1b 00  86 50 03 00 86 21 05 00  |.........P...!..|
00000010  71 4f 05 00 3d 64 8f fd  d3 6e 04 00 00 00 00 00  |qO..=d...n......|
00000020  00 00 00 00 19 69 04 00  00 02 00 00 01 00 00 00  |.....i..........|
00000030  00 00 00 00 5e 59 01 00  00 1d 00 00 00 00 00 00  |....^Y..........|

also, I ran my grab through a decoder and it found the first IDR header at 5090, first non-IDR (and first NAL) at 3838

[xannor]

I started to question the first tool I used so I got h26x-extractor, and it give better results (not sure why the other tool had offset byte values) the first non-IDR and valid NAL is 3834 and the first SPS is 5020, PPS is 5056

[roleoroleo]

From the memory header, how did you determine that +16 was the dword for the offset?

I simply did so many tests

and how did you decide the base offset is 300? my dump file is 16 bytes bigger.

I found the 1st byte that change when the buffer rotates.

Here is the first 64bytes of my dump (the rest till 316 are all zeros)

00000000  00 00 00 00 05 36 1b 00  1a 45 00 00 40 3c 0c 00  |.....6...E..@<..|
00000010  3b 46 0c 00 38 8c 4c fd  2e 2f 00 00 00 00 00 00  |;F..8.L../......|
00000020  00 00 00 00 09 2d 00 00  00 02 00 00 01 00 00 00  |.....-..........|
00000030  00 00 00 00 9a 11 00 00  00 1d 00 00 00 00 00 00  |................|

and here are a few recent grabs off of the device its self:

/home/app # hexdump -n 64 -vC /dev/shm/fshare_frame_buf
00000000  00 00 00 00 77 3e 1b 00  86 50 03 00 0c 8f 04 00  |....w>...P......|
00000010  95 90 04 00 0f 5c 8f fd  50 6e 04 00 00 00 00 00  |.....\..Pn......|
00000020  00 00 00 00 19 69 04 00  00 02 00 00 01 00 00 00  |.....i..........|
00000030  00 00 00 00 5e 59 01 00  00 1d 00 00 00 00 00 00  |....^Y..........|
00000040
/home/app # hexdump -n 64 -vC /dev/shm/fshare_frame_buf
00000000  00 00 00 00 e7 3f 1b 00  86 50 03 00 4b f6 04 00  |.....?...P..K...|
00000010  64 f6 04 00 b1 60 8f fd  9b 6e 04 00 00 00 00 00  |d....`...n......|
00000020  00 00 00 00 19 69 04 00  00 02 00 00 01 00 00 00  |.....i..........|
00000030  00 00 00 00 5e 59 01 00  00 1d 00 00 00 00 00 00  |....^Y..........|
00000040
/home/app # hexdump -n 64 -vC /dev/shm/fshare_frame_buf
00000000  00 00 00 00 15 12 1b 00  86 50 03 00 86 21 05 00  |.........P...!..|
00000010  71 4f 05 00 3d 64 8f fd  d3 6e 04 00 00 00 00 00  |qO..=d...n......|
00000020  00 00 00 00 19 69 04 00  00 02 00 00 01 00 00 00  |.....i..........|
00000030  00 00 00 00 5e 59 01 00  00 1d 00 00 00 00 00 00  |....^Y..........|

also, I ran my grab through a decoder and it found the first IDR header at 5090, first non-IDR (and first NAL) at 3838

You have to check the headers. Please, share a dump of fshare_frame_buf.

[xannor]

here is the dump that I have been testing with. grab.zip

[roleoroleo]

Inside this file, there are 5 different types of NALs:

• 00 00 00 01 67 42 40 1E A6 80 A0 31 F8 D4 - SPS
• 00 00 00 01 68 CE 3C 80 - PPS
• 00 00 00 01 65 ... - IDR
• 00 00 00 01 02 ... - ?
• 00 00 00 01 61 ... - ?

Each NAL (apart from the SPS) is preceded by a 22 bytes header. SPS has a second 6 bytes header. The 1st 4 bytes of the header are the length of the payload (packet without header).

A strange thing: I have not found different SPS headers for high res and low res.

Probably the byte number 17 (starting from 0) of the header is the resolution: 08 -> high res and 10 -> ?. And bytes 18 and 19 are the frame counter. I think the header structure is the same as Allwinner version.

But, in general, if the driver exposes the proc structure (i.e. /proc/mstar/OMX/*) it's easier.

[xannor]

unfortunately the only thing in the MStar folder under proc is a linux folder with some kernel info. there is no OMX. correction, under /proc/mstar is only a kernel folder that is empty.

[xannor]

shouldn't the SPS and PPS headers be constant as those are governed by a spec. What I could not determine was, going by your code, how to determine the "current" frame in the circular buffer. You code relies on a dword 16 bites into the start, and offsetting that by 300 to find the position. I could not match that up in the grab I provided.

[roleoroleo]

In the previous cams SPS and PPS headers are constant.

I don't know exactly where is the current frame. I "think" that the dword contains a write index of the circular buffer, so I look for a NAL with this address as upper limit. Then I wait for the index to move forward and look for a new NAL.

[xannor]

ah, ok, I read the cb_memmem wrong. I was thinking you only comparing not scanning forward.