MMAL API -- did it change in the last year?

[jwatte]

I have a program that worked fine last year in March, using MMAL to do image analysis on the "preview port" data (not actually on the display) and doing H.264 encoding on the main port to write to a file.

However, I recently did a full apt-get upgrade of everything, and that same code (with small modifications, unfortunately) now doesn't record anything more than 27 bytes -- one buffer of 9 bytes, and one buffer of 18 bytes.

The program started out with the RaspiVid.cpp code, but it got a whole host of things hacked out of it.

So -- did anything in the setup of the MMAL API change such that I'm missing something that should now be done?
The program still compiles cleanly with the userland directory from last year, for whatever that's worth.

[jwatte]

For example, I notice that a bunch of libraries that were there in 2015 aren't there now (they seem to be plugins, that perhaps moved to the /opt/vc/lib/plugins directory?)

What changes should I make to my source to make it work again?
Also, the source does not build with the NEW userland -- vc_gencmd() and vc_gencmd_number_property() seems to have gone away?
(This is not why the program doesn't work -- I don't actually need those symbols, but it tells me the userland somehow changed.)

[6by9]

Nope, no significant changes, and it's very rare for public library functions to be removed.

All of MMAL and gencmd is built from the userland repo
vc_gencmd: https://github.com/raspberrypi/userland ... cmd.c#L350
vc_gencmd_number_property: https://github.com/raspberrypi/userland ... cmd.c#L452

The 9 and 18 byte packets are the H264 SPS and PPS headers.
Have you actually presented any data to the codec to encode? Does RaspiVid still work?

[jwatte]

Raspivid built from the userland on github yesterday, works, as in it encodes H264 that VLC can play back.

However, it does NOT show the preview on the display, at least with -f (fullscreen) option which is the only one I tested. Is this a side effect of me now using the official PiTFT display and flat cable adaptor, rather than HDMI out?

I derived this code by hacking out a LOT of what Raspivid does, because I only need a fixed config and that only uses 1/10th of all the options at most.

But, somehow, there's some call I'm missing that arranges for the codec to get the data, that wasn't important before but is important now.

The build error is likely some change in library names or locations (or symbol locations within libraries) and is more a symptom that "at least something changed" -- I don't think you actually removed this function!


Now, if GDB would actually work for real, it wouldn't be so hard to trace through raspivid and my code to compare what they actually do for setup... (see other thread)

[jwatte]

Okay, with a modern version of gdb, debugging was easier, and it turns out I was passing FALSE to MMAL_PARAMETER_CAPTURE which made it not capture. Fancy that!

Thanks for the pointers, I do appreciate it.