h264_omx zerocopy causes Raspberry Pi to hang

[jasaw]

Summary of the bug:
When ​motion software uses libavcodec h264_omx to encode frames at 1280 x 720 resolution, it hangs when calling OMX_EmptyThisBuffer.

Works fine at 800 x 600 resolution.
Works fine at 1280 x 720 resolution if input_zerocopy is disabled in libavcodec/omx.c : omx_encode_init function.
Works fine if using ffmpeg binary to encode.

Tested on various models of Raspberry Pis, all show the same problem.

How to reproduce:

- motion git master 280141f, compiled from source, running on Raspbian Jessie.
- Raspberry Pi GPU firmware version: 3202f1b16896029f9da1b074b0912177e8960b52
- Make sure h264_omx encoder is used by motion:
  - either modify motion to specifically choose the encoder
  - or get ffmpeg to always default to h264_omx encoder when H264 format is selected
- Set resolution at 1280 x 720. Frame rate makes no difference.
- Record video into a movie file, mp4 format.
- Run motion and trigger some motion, and it will lock up.

Motion config file:

ffmpeg_output_movies on
height 720
stream_quality 5
threshold 28800
quality 85
noise_level 31
ffmpeg_output_debug_movies off
pre_capture 1
noise_tune on
smart_mask_speed 0
stream_maxrate 1
output_pictures off
hue 0
saturation 0
stream_localhost off
ffmpeg_variable_bitrate 75
ffmpeg_video_codec mp4
text_changes off
movie_filename %Y-%m-%d-%H-%M-%S
auto_brightness off
stream_port 8081
rotate 0
brightness 0
lightswitch 0
framerate 20
emulate_motion off
snapshot_filename
despeckle_filter
snapshot_interval 0
stream_auth_method 0
stream_motion off
target_dir /var/lib/motioneye/Camera1
text_double on
post_capture 100
stream_authentication user:
output_debug_pictures off
on_picture_save /usr/local/lib/python2.7/dist-packages/motioneye/scripts/relayevent.sh "/etc/motioneye/motioneye.conf" picture_save %t %f
on_movie_end /usr/local/lib/python2.7/dist-packages/motioneye/scripts/relayevent.sh "/etc/motioneye/motioneye.conf" movie_end %t %f
text_left Camera1
picture_filename
locate_motion_style redbox
locate_motion_mode off
contrast 0
videodevice /dev/video0
max_movie_time 0
on_event_end /usr/local/lib/python2.7/dist-packages/motioneye/scripts/relayevent.sh "/etc/motioneye/motioneye.conf" stop %t
text_right %Y-%m-%d\n%T
on_event_start /usr/local/lib/python2.7/dist-packages/motioneye/scripts/relayevent.sh "/etc/motioneye/motioneye.conf" start %t
event_gap 30
minimum_motion_frames 15
mask_file
width 1280

[jasaw]

Motion patch to choose h264_omx encoder

[jasaw]

motion config file

[jasaw]

It appears that whenever the zerocopy condition in omx.c is satisfied (contiguous planes and stride alignment), the call to OMX_EmptyThisBuffer hangs. 1280 x 720 resolution images captured from the Pi camera happens to meet that condition.

This explains why it works when zerocopy is disabled.

[jasaw]

Since this issue is most likely a VCHIQ kernel driver issue, ffmpeg should not force enable zerocopy that triggers this bug, i.e. remove the below code from "omx_encode_init" function.

#if CONFIG_OMX_RPI
    s->input_zerocopy = 1;
#endif

[Aman]

Sounds like this is an upstream rpi firmware issue. However ffmpeg doesn't respect the zerocopy option when compiled for RPI which makes this hard to work-around. I'll work on a patch to default zerocopy to enabled on RPI builds but still let the user disable it in case they run into this bug.

[Carl Eugen Hoyos]

Pushed as 23a3e1460a7a609651bfe75b7b4c428eaa8f3902