ffmpeg & h264_omx on pi3 very slow

[drhans]

transoding h264 1080i @ 15Mbps to h264_omx still kills the raspberry, CPU running at 150%, resulting in choppy video - any suggestions?

Code: Select all

./ffmpeg -i "http://pi:17999/stream/service/1c7d56b7dbf9cf0f51c0b9a6e4fe1eda?profile=pass&descramble=0&emm=1&:0:0:d" -f mpeg2video -vcodec h264_omx -probesize 32 -analyzeduration 0 -f mpegts -

pi3 cpu at 150+ %, transoded output choppy, unwatchable

[dickon]

Have you got any buffering?

[freman]

Which version of ffmpeg are you using?
ffmpeg-3.1 now supports hardware assist h264 encoding.

I did a quick test on my RPI3:
./ffmpeg-3.1 -f v4l2 -input_format yuv420p -framerate 30 -video_size 720x480 -i /dev/video0 -frames 5000 -an test.h264

the cpu was less than 8% busy...

[ILiveAHoodie]

What OS did you install FFmpeg 3.1 on? Is this working on Raspbian (Jessie)? Very interested in hardware h264 on RP.

[freman]

Hi,
I am using jessie.
uname -a
Linux raspberrypi 4.4.13-v7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux

[ILiveAHoodie]

Did you download and install the official repo from the website.

git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg

What compile commands did you use?

Im running Jessie and would like to attempt your same configuration. Will let you know if i get the same results.

[ILiveAHoodie]

Ok. I've been able to compile FFMPEG 3.1 with omx enabled. On my test I've been getting 12-13fps when converting gopro video to a lower end h264. It should also be noted that if you give it any filters (like scale) it slows down to 4fps or less. Those are my results.

[jbeale]

What resolution are you using? For what it's worth, I was able to get 10 fps encoding doing a live recording from a 1280x720 webcam with this command:

Code: Select all

ffmpeg -f video4linux2 -i /dev/video0 -s 1280x720 -c:v h264_omx  output.mp4

and that speed limit was due to the USB source device, not due to ffmpeg. I may have actually got 30 fps at 1280x720 using the MJPEG format from the webcam instead of YUYV, but I'll have to check when I get back to my desk.

[ILiveAHoodie]

In my tests i was using a 15Mbps h264 video at 1920x1080, 29.97. Going down to 4Mbps h264 ran at 12-13fps while converting. Adding a scale filter to 1280x720 made it convert at 4fps.

[jbeale]

If the source was already in h.264 format then you have to decode, then re-encode so I assume that cut down the speed relative to encoding from raw.

[ILiveAHoodie]

I've tested with an HD MOV file under low compression. It averaged a transcode speed of 1.4 FPS going to H264.
Is anyone else getting speeds like this?

[gkreidl]

Perhaps you should use gstreamer-1.0 and the gst-omx module. I use it for real time transcoding of all kinds of sources (756p h264 and MPEG2, 720p50 H264 and 1080i50) to lower resolutions and bit rates.

[ILiveAHoodie]

Does gst-omx have a plugin for FFMPEG? I've never used it before.

[gkreidl]

Does gst-omx have a plugin for FFMPEG? I've never used it before.

No. gst-omx is a plugin for gstreamer-1.0. You could use gst-launch-1.0 with a tool chain to replace what you are trying to do with ffmpeg. But it's a real pain to use.

[blackshard83]

Don't expect miracles, the h264 hardware encoder is pretty basic and produces very low quality output even at high bitrates, and software encoding is still very slow on ARM machines.

[gkreidl]

Don't expect miracles, the h264 hardware encoder is pretty basic and produces very low quality output even at high bitrates, and software encoding is still very slow on ARM machines.

No, the quality is quite good, even if it cannot compare with a multipass software encoder. I'm using it all the time.
And encoding by software isn't that slow with Handbrake (using NEON). SD video can be re-encoded faster than real time.