MMAL blocks on mmal_component_disable

[spacehamster]

When mmal components are set up in certain configurations, presumably misconfigured, such as connecting a splitter component to the camera still port, the program never returns from vcos_semaphore_wait in mmal_component_disable(camera_component). If the program is killed and then started again, it blocks at mmal_component_create(camera_component). Is there a way of finding out when the components aren't configured properly or resetting mmal without rebooting the whole os?

[spacehamster]

It wasn't connecting a splitter component to the still port that caused the problem, but rather connecting an image_encode component to the splitter port, setting the encoding to PNG, BMP or GIF (but not JPEG), setting the resolution to 1920x1080 (not 2592x1944) and not creating a preview component.

It also happens when I

• connect a MJPEG video encoder component to the preview port
• connect a PNG or GIF image encoder the preview port with a splitter which causes vcdbg log msg to output vcos_abort: Halting and vcodbg log assert to output
  assert( *p==0xa55a5aa5 ) failed; ../../../../../vcfw/rtos/common/rtos_common_malloc.c::rtos_pool_aligned_free line 205 rev a3d7660
• connect a JPEG image encoder to the video port which causes vcdbg log msg to output vcos_abort: Halting and vcodbg log assert to output
  assert( ! (IS_ALIAS_NORMAL(Y) || IS_ALIAS_NORMAL(U) || IS_ALIAS_NORMAL(V)) ) failed; ../../../../../codecs/image/jpeghw/codec/jpe_enc.c::jpe_enc_rectangle line 295 rev a3d7660
• connecting a PNG, GIF or BMP image encoder to the video port caused the whole os to lockup and become completely unresponsive

[6by9]

In answer to your original question, no there is no easy way to restart the MMAL service on the VPU if it wedges.
This sounds more of a fatal issue in the components than mmal_component_disable itself.

• MJPEG to preview port should work. I'm guessing you're using MMAL_ENCODING_OPAQUE.
• PNG/GIF to preview is a memory trample to fire that assert/abort - 0xa55a5aa5 is the guard word around an allocation. Again confirmation that you're using MMAL_ENCODING_OPAQUE (or what you are using if not) would be useful.
• JPEG image encode to video port is a memory alias assert as the hardware block can't access cached memory. (a) it shouldn't be an abort as it isn't fatal (the JPEG codec like throwing toys out of the pram), and (b) I thought that was a standard use case with PiCamera (capture(video_port=true)), so I'm a little surprised it doesn't work.
• PNG/GIF/BMP image_encode again sounds like a memory trample that is managed to take out stuff.

I'll have a look at these when in the office tomorrow. If you have any simple test apps that I can just run rather than having to write my own then it'd be most appreciated. (Then again it should be easy to hack raspistill to achieve these configs).

[spacehamster]

All the camera_component ports are set to MMAL_ENCODING_OPAQUE with encoding_variant MMAL_ENCODING_I420

I'm still trying to wrap my head around the api, so the code is a bit messy but I've uploaded a test app here:
https://github.com/spacehamster/Picam

[6by9]

Thanks for the sample code - that saved me a lot of time.

I've had a look through. The cases you're reporting a vcos_abort, which I believe are:
"2 1" camera video port-> splitter -> image_encode PNG
"3 4" camera preview port -> image_encode JPEG
"4 1" camera video port -> image_encode PNG
all are linked to a common image conversion that is required within image_encode. In the first case it appears to trashing memory. In the second case it's because the allocation is from the wrong cache alias and the JPEG codec throws its toys out of the pram rather than aborting cleanly (grr). The third case is similar to the first and is trashing memory.

Likewise your crash from "2 4" (PNG), "4 4" (BMP), and "5 4" (GIF) are the same root cause, just that the VPU trashes more of memory and has taken out the kernel.

"8 2" (textures off the stills port via a splitter) I'm not going to look at as textures isn't my thing, and it doesn't really have a valid use case.

"1 0" and "1 3" (MJPEG from preview port) is several things.

• Firstly you haven't set the framerate (video_encode output port), so there's a divide by 0 when computing the number of bytes per frame.
• Secondly is that video_encode is not set up to run from the preview port, so some signalling is missing and results in incorrect image conversion.
• Finally is the known issue of the codec wedging if you haven't cleared the output FIFO sufficiently. It's an involved one to fix which requires a significant rewrite of the codec code.

TBH Connecting video_encode using MMAL_ENCODING_OPAQUE to anything other than camera video port, video_decode, or image_fx (mainly for deinterlace) is likely to cause issues, and I'm not sure the use case is strong enough to warrant huge investigation into fixing it up for other cases. Opaque handling is doing rather a lot under the bonnet which isn't always fully generic, and with those use cases there isn't a performance saving over using raw pixel buffers (eg MMAL_ENCODING_I420) as there is when you use the ports it is intended for.

[6by9]

In better news, I think I've just found why we get memory corruption with the conversion. The fix should be relatively trivial.

[6by9]

I missed out "11 5" - JPEG_NO_PREVIEW from the STILL port. Again that's not a useful use case as there will have been no auto exposure or white balance adaptation, so most likely to get randomly coloured and incorrectly exposed images.

[6by9]

So I have a fix, and now
"2 4"
"4 4"
"5 4"
"2 1"
"4 1"
all work.

"3 4" I'd slightly mis-diagnosed and is more difficult to sort.
I've reopened #390 as that was where I was handling the mismatch of opaque buffers.

[6by9]

Fixes got merged on 3rd Nov to the rpi-update releases.
Please run "sudo rpi-update" on a non-critical Pi (backup first!) and retest.

[JamesH65]

Please update to the latest software which now contains a fix for this issue.

Please reopen if you encounter any issues with this change.