Opened 2 years ago

Closed 3 weeks ago

#6586 closed defect (fixed)

h264_omx zerocopy causes Raspberry Pi to hang

Reported by: jasaw Owned by: tmm1
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 2 years ago.
Motion patch to choose h264_omx encoder
thread-1.conf (1.4 KB) - added by jasaw 2 years ago.
motion config file

Download all attachments as: .zip

Change History (8)

Changed 2 years ago by jasaw

Motion patch to choose h264_omx encoder

Changed 2 years ago by jasaw

motion config file

comment:1 Changed 2 years 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.

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

comment:3 Changed 8 months ago by jasaw

  • Keywords zerocopy added
  • Summary changed from motion using h264_omx hangs on Raspberry Pi to h264_omx zerocopy causes Raspberry Pi to hang

comment:4 Changed 8 months ago by cehoyos

  • Keywords zerocopy removed

comment:5 Changed 4 weeks ago by tmm1

  • Cc ffmpeg@tmm1.net added
  • Owner set to tmm1
  • Status changed from new to open

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 Changed 3 weeks ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.