Hi,
I'd very much like to contribute to some utilities for the camera module and scratch an itch around motion detection, but feeling a bit lost trying to learn MMAL.
I've found only a couple links like this one (http://blog.oklahome.net/2014/09/what-i ... berry.html) of people explaining how MMAL works (besides the overview at http://www.jvcref.com/files/PI/documentation/html/), but there isn't much. A better example that's been easier for me to follow than say raspivid is this one: https://github.com/tasanakorn/rpi-mmal-demo .
Still, maybe because I haven't done much C or stuff with video/multimedia I'm finding it quite hard. Is there anything else I can read or do other than just keeping at it, reading the sources in userland and experimenting?
I'm also still relatively confused about videocore, openmax, when and what runs things on the GPU (it seems that cannot be accessed directly and only the blobl can?), vcos and vchi, etc, but maybe I don't need all of that at this time.
happy to rtfm/jfgi, reading the sources and generally walking the walk, but some pointers about directions would be useful so that I don't end up running around in circles.
thanks,
Spike
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 15291
- Joined: Wed Dec 04, 2013 11:27 am
- Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.
Re: Help learning MMAL/contributing to userland utils
Answering some of your questions about acronyms and what runs where:
VideoCore (often abbreviated to VC) is the GPU and associated multimedia peripherals. It also includes the 3D engine, and the QPUs (Quad Processor Units) that sit alongside the 3D hardware. There is a SIMD vector processor in there which is what runs the firmware blob, sometimes referred to as the VPU (Vector Processor Unit).
Comms to VC is over VCHIQ - VideoCore Host Interface Queue. There have been other flavours of VCHI for other projects, but they aren't relevant here.
Various services sit on top of VCHIQ, such as vcgencmd for mainly debug stuff, and IL and MMAL.
VCOS - VideoCore OS abstraction. Just a wrapper around the library of functions that need to shift between operating systems under Linux, the RTOS on the VPU, and various other platforms that had to be supported over the years.
OpenMaxIL (Integration Layer) is a a Khronos standardised API for multimedia. It's a bit of a pig to use.
MMAL (MultiMedia Abstraction Layer) was the Broadcom approach to fixing the issues found with IL at a point when IL became less important.
Both IL and MMAL share the same underlying code on the VPU to implement the functionality, they are just accessed in different ways. Whist it is possible to run either IL or MMAL components on the ARM, all the main components that get used on Pi run on VideoCore as they want access to the hardware blocks.
All hardware blocks can be accessed, but docs have not been released for all of them. Originally things like the SD card peripheral and GPIOs were considered part of VideoCore, but those have been documented, and drivers implemented for Linux. Likewise the 3D hardware is documented, and some people are trying to shift the 3D control code to the ARM with varying degrees of success.
As for a discussion about MMAL, AFAIK the only official docs are the headers. Being originally an internal API documentation wasn't always the highest priority.
Basic premise is that components have ports. You configure formats on those ports, and then enable them with a callback function for when a buffer is returned. Buffers belong to pools, and typically you call mmal_buffer_header_release when you're done with a buffer, and attach a callback to the pool for when buffers are returned to the pool in order for you to send them back to the relevant place.
VideoCore (often abbreviated to VC) is the GPU and associated multimedia peripherals. It also includes the 3D engine, and the QPUs (Quad Processor Units) that sit alongside the 3D hardware. There is a SIMD vector processor in there which is what runs the firmware blob, sometimes referred to as the VPU (Vector Processor Unit).
Comms to VC is over VCHIQ - VideoCore Host Interface Queue. There have been other flavours of VCHI for other projects, but they aren't relevant here.
Various services sit on top of VCHIQ, such as vcgencmd for mainly debug stuff, and IL and MMAL.
VCOS - VideoCore OS abstraction. Just a wrapper around the library of functions that need to shift between operating systems under Linux, the RTOS on the VPU, and various other platforms that had to be supported over the years.
OpenMaxIL (Integration Layer) is a a Khronos standardised API for multimedia. It's a bit of a pig to use.
MMAL (MultiMedia Abstraction Layer) was the Broadcom approach to fixing the issues found with IL at a point when IL became less important.
Both IL and MMAL share the same underlying code on the VPU to implement the functionality, they are just accessed in different ways. Whist it is possible to run either IL or MMAL components on the ARM, all the main components that get used on Pi run on VideoCore as they want access to the hardware blocks.
All hardware blocks can be accessed, but docs have not been released for all of them. Originally things like the SD card peripheral and GPIOs were considered part of VideoCore, but those have been documented, and drivers implemented for Linux. Likewise the 3D hardware is documented, and some people are trying to shift the 3D control code to the ARM with varying degrees of success.
As for a discussion about MMAL, AFAIK the only official docs are the headers. Being originally an internal API documentation wasn't always the highest priority.
Basic premise is that components have ports. You configure formats on those ports, and then enable them with a callback function for when a buffer is returned. Buffers belong to pools, and typically you call mmal_buffer_header_release when you're done with a buffer, and attach a callback to the pool for when buffers are returned to the pool in order for you to send them back to the relevant place.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.
I'm not interested in doing contracts for bespoke functionality - please don't ask.