0

The context is transcoding on a Raspberry Pi 3 from 1080i MPEG2 TS to 1080p@30fps H264 MP4 using libav avconv or ffmpeg. Both are using almost idenitical omx.c source file and share the same result.

The performance is short of 30fps (about 22fps) which makes it unsuitable for live transcoding without reducing the frame rate.

By timestamping the critical code, I noticed the following:

  1. OMX_EmptyThisBuffer can take 10-20 msec to return. The spec/document indicates that this should be < 5msec. This along would almost account for the performance deficit. Can someone explains why this OMX call is out of spec?

  2. In omx.c, a zerocopy option is used to optimized the image copying performance. But the precondition (contiguous planes and stride alignment) for this code is never satisfied and this the optimization was never in effect. Can someone explain how this zerocopy optimization can be employed?

Additional question on h264_omx encoder: it seems to on accept MP4 or raw H264 output format. How difficult it is to add other format, e.g. TS?

Thanks

A. H.
  • 1
  • 2
  • What operating system are you using? Did you compile ffmpeg yourself? – dbmitch Sep 29 '16 at 20:36
  • raspbian distro version 4.4.22. – A. H. Sep 29 '16 at 21:19
  • Compiled ffmpeg version N-81780-g4a05d2e on RPi3 with --enable-mmal –enable-omx-rpi – A. H. Sep 29 '16 at 21:20
  • I don't know what's in that version. I usually pull from git and configure with arm and libx264 options Did you use `make -j4` to take advantage of the four cores? – dbmitch Sep 29 '16 at 22:30
  • make -j4 should help the make performance. This would help runtime performance of ffmpeg? The ffmpeg version is only a few day old. I am assuming by using h264_omx, libx264 would not be used for encoding. – A. H. Sep 29 '16 at 23:23

0 Answers0