hopkinskong
Posts: 22
Joined: Sun Jul 03, 2016 9:35 am
Location: Hong Kong

img_encode Seg. Fault at 1920x1080

Mon Jun 05, 2017 6:36 pm

Hi,

I am using IL to encode BGR888 frames to JPEG using image_encode.

The code is here:
https://raw.githubusercontent.com/hopki ... _bench.cpp

I have tested 1280x720 and 640x480 images with no issues. However, when I replace with 1920x1080 images, I get Seg. Fault.

I have traced the issue to the second-last buffer filling (67th filling, filling starting from 6082560, 92160 bytes in size), where there are total 68 times needed to fill the buffer, with the last one only fills half of the buffer. After calling OMX_EmptyThisBuffer for the 67th filling, the application has still run a while in the main loop (so calling OMX_EmptyThisBuffer does NOT trigger Seg. Fault immediately), then Seg. Fault.

Running GDB didn't show much of the information, it just saying the program fails in memcmp().

Note that the output JPEG image is decodable, the upper part is correct, only with the lower part be blank (or undecodable).

Any idea what's going wrong?

Thanks.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4426
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: img_encode Seg. Fault at 1920x1080

Tue Jun 06, 2017 1:11 pm

Please simplify the project to remove all the non-essential OpenCV lumps, and include your headers (you're including a jpeg_bench_image.h which you haven't supplied).
I could pick through the code, but it'd be much quicker to be able to run your test case.

If you've run it with gdb, what's the full backtrace when it seg faults? You don't appear to call memcmp directly, so it's difficult to even hazard a guess as to where it is failing.
Note that the output JPEG image is decodable, the upper part is correct, only with the lower part be blank (or undecodable).
That's normal when the encoded data is truncated. The decoder typically fills the buffer with either grey or green before decoding, and that is left there if the decode fails part way through.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4426
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: img_encode Seg. Fault at 1920x1080

Tue Jun 06, 2017 2:56 pm

My bad on source - you'd referenced one file so I'd read it as being a gist rather than the raw file out of a repo. Looking at https://github.com/hopkinskong/rpi-omx-jpeg-encode/ gives me the full context.

I've got a fair guess at what is happening.
https://github.com/hopkinskong/rpi-omx- ... h.cpp#L642 you're allocating a buffer that is 1920*1080*3 = 6220800 bytes.
https://github.com/hopkinskong/rpi-omx- ... h.cpp#L652 is then memcpying from that buffer into the IL buffer.
IMAGE_HEIGHT / nSliceHeight = 1080 / 16 = 67.5. So on the 68th iteration there is only half a buffer available to copy. You still copy the full WIDTH*nSliceHeight*CHANNELS, therefore memcpy (not memcmp!) will seg fault as you're reading off the end of that buffer.

You want to do a memcpy of something like min(imgMatSize-imgMatPtrPos, slicesize) bytes and set nFilledLen accordingly.
(NB For YUV420PackedPlanar you still have to provide a full slice as the U&V offsets are based on a full slice instead of just the bit that you've filled).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

hopkinskong
Posts: 22
Joined: Sun Jul 03, 2016 9:35 am
Location: Hong Kong

Re: img_encode Seg. Fault at 1920x1080

Tue Jun 06, 2017 5:48 pm

Issue fixed after debugging awhile, thanks for you help.

EDIT:
Yes, you are right, that's the exact issue. In fact, I have already considered this, but it seems my head is not straight when I am writing the code :cry: , simply reversing the order of adding offset and checking last slice fixes the issue:

https://github.com/hopkinskong/rpi-omx- ... 8dd50e8864

Return to “OpenMAX”

Who is online

Users browsing this forum: No registered users and 1 guest