Motioneyeos: h264_omx does not work on Raspberry Pi 4

[lukasig]

Hi
I am new to reporting issues so please bear with me.

I have been running motioneyeos on a raspberry pi 2 for the last two years with no problems.
Since pi 4 came out and me planing to add more cameras, I purchased a pi 4 (1GB version) and have been testing the images provided in the dev version.

I have the exact same settings on both systems, saving footage only when motion is detected through a editable mask.
Both systems detect motion (flashing the camera frame red), but the pi4 does not save the footage - no media files are created or saved.

If I can help with additional info, please let me know.

thanks

[ovaltineo]

The default movie format H.264/OMX is not working on Pi4. Choose another format like H.264.

[lukasig]

That worked. Should we expect OMX working soon?

[jasaw]

I'm marking this issue as a bug so we don't forget about it.
I haven't got a RPi 4, so I can't look into this issue yet.

[ccrisan]

I (hopefully) disabled OMX support on the Raspberry Pi4 for now so it doesn't show up in motionEye anymore.

[jasaw]

@ccrisan Have you tried h264_omx on RPi4 with latest rpi-firmware?

[ccrisan]

@jasaw not yet. Do they say they have proper h264 OMX support on the RPi4 now?

[jasaw]

I found a ffmpeg bug report that claims h264_mmal and h264_omx transcoding is working with latest rpi firmware. I haven't got a chance to test it myself.

[jasaw]

This is the ffmpeg bug report that I was referring to https://trac.ffmpeg.org/ticket/8018

[mdPlusPlus]

I have access to a Raspberry Pi 4B. How can I help to test this?

EDIT:
FIrmware updated to a73aff718fc2ea04982de933505c7b5bd440e854 with rpi-update.
Bootloader updated to f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (latest non-beta) with rpi-eeprom.

[mdPlusPlus]

@ccrisan If I wanted to try this on my RPi 4B (possibly with different firmware versions), is 5a55f768a4602b2eefa525fbfa25ed8556759ef9 the only commit I would have to revert?

[ccrisan]

@mdPlusPlus in theory, yes. Keep us posted.

[mdPlusPlus]

So, I checked out bb99c99698859ce5f1bcdbfb9c86151c34e6b582 (tag 20190911), git reverted the commit 5a55f768a4602b2eefa525fbfa25ed8556759ef9 and built the raspberrypi4 image.
I'm still not able to get video recorded.

# cat /var/log/motion.log

[0:motion] [NTC] [ALL] conf_load: Processing thread 0 - config file /data/etc/motion.conf
[0:motion] [NTC] [ALL] config_camera: Processing camera config file camera-1.conf
[0:motion] [NTC] [ALL] motion_startup: Logging to syslog
[0:motion] [NTC] [ALL] motion_startup: Motion 4.2.2 Started
[0:motion] [NTC] [ALL] motion_startup: Using default log type (ALL)
[0:motion] [NTC] [ALL] motion_startup: Using log type (ALL) log level (WRN)
[1:ml1:Camera1] [ERR] [ENC] ffmpeg_set_codec: Could not open codec Encoder not found
[1:ml1:Camera1] [ERR] [ENC] ffmpeg_open: Failed to allocate codec!
[1:ml1:Camera1] [ERR] [EVT] event_ffmpeg_newfile: Error opening context for movie output.
[1:ml1:Camera1] [ERR] [ENC] ffmpeg_set_codec: Could not open codec Encoder not found
[1:ml1:Camera1] [ERR] [ENC] ffmpeg_open: Failed to allocate codec!
[1:ml1:Camera1] [ERR] [EVT] event_ffmpeg_newfile: Error opening context for movie output.
[1:ml1:Camera1] [ERR] [ENC] ffmpeg_set_codec: Could not open codec Encoder not found
[1:ml1:Camera1] [ERR] [ENC] ffmpeg_open: Failed to allocate codec!
[1:ml1:Camera1] [ERR] [EVT] event_ffmpeg_newfile: Error opening context for movie output.

Apparently it doesn't work with the aforementioned bootloader/eeprom version. ffmpeg tells me the h264_omx encoder is available (or atleast that it got compiled with support for it):

# ffmpeg -encoders | grep -i omx

V..... h264_omx             OpenMAX IL H.264 video encoder (codec h264)

EDIT: Do I need to manually patch ffmpeg according to https://github.com/ccrisan/motioneye/issues/930?

EDIT2: Okay, so apparently I was under the wrong impression, that rpi-update (under Raspbian) would actually update stuff on the Pi's EEPROM. Only rpi-eeprom-update does that. However, updating the EEPROM contents to the newest available beta release (Mon Nov 18 11:06:55 UTC 2019 (1574075215) and 000137ab) has no effect on h264_omx working or not. After further research this is just for the bootloader and the USB chipset firmware, so this was to be expected.
Guess I'll have to check whether rpi-update will work under MotionEyeOS now.

EDIT3:

 # SKIP_KERNEL=1 ./rpi-update

 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 !!! This tool requires you have readelf installed, please install it first
     In Debian, try: sudo apt-get install binutils
     In Arch, try: pacman -S binutils

So, since rpi-update apparently isn't that easy to run under MotionEyeOS, I guess I need to get MotionEye to work on Raspbian to see whether this will work in the end or not.

[mdPlusPlus]

I don't really know what to exactly make of this, but running the MotionEye docker container on top of Raspbian results in being able to record h264_omx video.

This is the command I used to run the container:

docker run --name="motioneye" \
    -p 8765:8765 \
    --hostname="motioneye" \
    -v /etc/localtime:/etc/localtime:ro \
    -v /etc/motioneye:/etc/motioneye \
    -v /var/lib/motioneye:/var/lib/motioneye \
    --restart="always" \
    --detach=true \
    --device=/dev/video0 \
    ccrisan/motioneye:master-armhf

So, I guess MotionEyeOS has to include newer firmware. At least newer than in the 20190911 release. I should probably test whether this is fixed by reverting commit 5a55f768a4602b2eefa525fbfa25ed8556759ef9 in the dev branch.

EDIT: Also, while I'm at it:

$ ./build.sh clean-target

unknown board: clean-target

This should probably be fixed.

EDIT2: So, even after removing the line from the dev branch and compiling the image again, I'm not able to record video with the h264_omx encoder.
I'm not entirely certain what the difference between the firmware shipped by MotionEyeOS and the one by current Raspian is, but that's what's enabling/disabling OMX encoding.
Unfortunately, I don't think I can be of further help with this issue as my knowledge of Raspberry Pi firmware is very limited.

[mdPlusPlus]

Addendum:
I tried updating the firmware on the dev image by running sudo ROOT_PATH=/PATH/TO/FORMER/220MB/PARTITION BOOT_PATH=/PATH/TO/BOOT/PARTITION ./rpi-update, but the Pi does not come up after that. (Note: I had to increase the size of the 220MB partition, I chose 900MB).

[mdPlusPlus]

@ccrisan How would I go about adding the newest stable Raspberry Pi firmware (https://github.com/raspberrypi/firmware/commit/b9f83b14a8f8ea11e4cc509da037d05836efa00f) to the dev branch to test it?

I realize I have to edit package/rpi-firmware/rpi-firmware.hash and package/rpi-firmware/rpi-firmware.mk, but I can't figure out which sha256 value to put in.
Also, while b9f83b1 is stable, there isn't a release tarball yet. Is that a problem?

[ccrisan]

@mdPlusPlus commits https://github.com/ccrisan/motioneyeos/commit/733326800de327847a8ad911c64c1b1ad82ecbaa, https://github.com/ccrisan/motioneyeos/commit/8526e553e82ac8de5654c0210438c99de4b1bd1a and https://github.com/ccrisan/motioneyeos/commit/d53b4c14a7c4041d1819afc69a77ea52778d26a0 bring the kernel, firmware and userland to latest stable version. You shouldn't worry about that anymore if you use the latest dev.

[mdPlusPlus]

@ccrisan Please check again. Apparently there is a hash mismatch for https://codeload.github.com/raspberrypi/userland/tar.gz/13b33c8ee52521ac3c804ffa6d8e8b8a8cd30697.

ERROR: rpi-userland-13b33c8ee52521ac3c804ffa6d8e8b8a8cd30697.tar.gz has wrong sha256 hash:
ERROR: expected: 3d31967d87c6d825ee73d1a5b8f39a53f2a006f7ff2903d7f628503248e62897
ERROR: got     : 1e0d4e7b837c9d36f5e987dd50ffad6d9c091e24e8638356399dba5d45866282
ERROR: Incomplete download, or man-in-the-middle (MITM) attack

I also get two 404 errors after that for http://sources.buildroot.net/rpi-userland/rpi-userland-13b33c8ee52521ac3c804ffa6d8e8b8a8cd30697.tar.gz and http://sources.buildroot.net/rpi-userland-13b33c8ee52521ac3c804ffa6d8e8b8a8cd30697.tar.gz.
Apparently they aren't up yet.

[ccrisan]

@mdPlusPlus you're right. Fixed in https://github.com/ccrisan/motioneyeos/commit/3beae4b26ab3b202a7ba2284cdd70dc8d744939d.

[mdPlusPlus]

@ccrisan Actually, I get another mismatch now:

 ERROR: rpi-firmware-878d27e23ff2f1c9a35d1b1fc8fe71e06083b823.tar.gz has wrong sha256 hash:
 ERROR: expected: 92ac14e7af3ac0f30271c9de903ee237f9f77e31583000281324cb1d8100ae95
 ERROR: got     : 032b17718bc1c7a818d8680db26d9d2a532fdafd861f3aad6ec6fdf7889fff78
 ERROR: Incomplete download, or man-in-the-middle (MITM) attack

After fixing the hash manually it seems to build just fine (so far, will update if another error occurs).

[ccrisan]

@mdPlusPlus you're right again. Fixed in https://github.com/ccrisan/motioneyeos/commit/92f77349d3c996a3e7aa95be6277ae44c85ff3ad.

[mdPlusPlus]

Unfortunately, this issue is still present:

# cat /var/log/motion.log

[0:motion] [NTC] [ALL] conf_load: Processing thread 0 - config file /data/etc/motion.conf
[0:motion] [NTC] [ALL] config_camera: Processing camera config file camera-1.conf
[0:motion] [NTC] [ALL] motion_startup: Logging to syslog
[0:motion] [NTC] [ALL] motion_startup: Motion 4.2.2+gitUNKNOWN Started
[0:motion] [NTC] [ALL] motion_startup: Using default log type (ALL)
[0:motion] [NTC] [ALL] motion_startup: Using log type (ALL) log level (WRN)
[1:ml1:Camera1] [ERR] [ENC] ffmpeg_set_codec: Could not open codec Encoder not found
[1:ml1:Camera1] [ERR] [ENC] ffmpeg_open: Failed to allocate codec!
[1:ml1:Camera1] [ERR] [EVT] event_ffmpeg_newfile: Error opening context for movie output.

P.S.: Also, this isn't fixed yet:

$ ./build.sh clean-target

unknown board: clean-target

[jasaw]

https://github.com/ccrisan/motioneyeos/pull/2226 should address this issue.