Opened 2 months ago

Last modified 2 months ago

#6586 new defect

motion using h264_omx hangs on Raspberry Pi

Reported by: jasaw Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: h264_omx, omx
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Attachments (2)

prefer-omx-encoders.patch (847 bytes) - added by jasaw 2 months ago.
Motion patch to choose h264_omx encoder
thread-1.conf (1.4 KB) - added by jasaw 2 months ago.
motion config file

Download all attachments as: .zip

Change History (3)

Changed 2 months ago by jasaw

Motion patch to choose h264_omx encoder

Changed 2 months ago by jasaw

motion config file

comment:1 Changed 2 months ago by 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.

Note: See TracTickets for help on using tickets.