Opened 7 years ago

Closed 5 years ago

#6586 closed defect (fixed)

h264_omx zerocopy causes Raspberry Pi to hang

Reported by: jasaw Owned by: Aman
Priority: normal Component: avcodec
Version: git-master Keywords: h264_omx omx
Cc: ffmpeg@tmm1.net 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 7 years ago.
Motion patch to choose h264_omx encoder
thread-1.conf (1.4 KB ) - added by jasaw 7 years ago.
motion config file

Download all attachments as: .zip

Change History (8)

by jasaw, 7 years ago

Attachment: prefer-omx-encoders.patch added

Motion patch to choose h264_omx encoder

by jasaw, 7 years ago

Attachment: thread-1.conf added

motion config file

comment:1 by jasaw, 7 years ago

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.

comment:2 by jasaw, 5 years ago

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

comment:3 by jasaw, 5 years ago

Keywords: zerocopy added
Summary: motion using h264_omx hangs on Raspberry Pih264_omx zerocopy causes Raspberry Pi to hang

comment:4 by Carl Eugen Hoyos, 5 years ago

Keywords: zerocopy removed

comment:5 by Aman, 5 years ago

Cc: ffmpeg@tmm1.net added
Owner: set to Aman
Status: newopen

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.

comment:6 by Carl Eugen Hoyos, 5 years ago

Resolution: fixed
Status: openclosed
Note: See TracTickets for help on using tickets.