33

I stumbled over the Wikipedia-article that the Broadcom GPU has hardware support for encoding H.264/AVC, not only de-coding.

I also found an article where someone gave an example using ffmpeg to generate a h264/mp4 video files. Ok, its a general-purpose CPU with a specialised GPU, so that's not really the surprise.

But compared to a standard desktop PC with an average Graphics-Card, will the Raspberry Pi potentially encode H.264/AVC maybe even faster? If a desktop user was to optimize his ffmpeg to his Core-i5xxx with $150 Ati/Nvidia graphics card... does that combination offer anything in the ways of "hardware H.264 encoding support"? If not, will a specially adopted Raspberry-Pi-ffmpeg be even faster? If yes, is there a speed comparison already?

Improve this question
4
  • I shouldn't think the Raspberry Pi will be faster than a desktop PC.
    – Jivings
    Dec 10, 2012 at 19:25
  • 5
    Somebody should clearly do a benchmark and show some results.
    – XTL
    Dec 13, 2012 at 8:01
  • @XTL Can you do that? ;-)
    – towi
    Aug 26, 2013 at 5:37
  • This is very good result..can you please add audio transcoding to example command?
    – user29056
    Apr 16, 2015 at 21:13

3 Answers 3

Reset to default
6

At the moment, it seems there is still no stable software to encode h264 video using the hardware, even if it has been officially announced that the Raspberry Pi does support h264 hardware-encoding. So, we cannot do a benchmark to compare performances to a regular PC.

I don't know if someone is working on the subject, but a developer from libav seems pessimistic about integrating such a module in the existing libav project (see his reply on december the 2nd, 09:23).

I'll be glad to do a benchmark when a library or software allows it.

Improve this answer
2
  • I have no idea where to start, but I might be willing to give it a try. I always searched for a reason for me to dig into libavcodec src, or -- to be precise -- x264.
    – towi
    Dec 14, 2012 at 12:37
  • 2
    The GStreamer library is capable of hooking into the Broadcom chips OpenMax API, and that does seem to be a able to do hardware encoding: gstreamer.freedesktop.org/releases/gst-omx/1.0.0.html
    – speedplane
    Dec 29, 2014 at 20:30
30

As of April 2015 GStreamer 1.2 included in Raspbian supports OpenMAX hardware accelerated H.264 encoding through omxh264enc.

I've done some benchmarking comparing:

  1. MacBook Pro (Early 2011) dual-core i7-2620M 2.7GHz (Sandy Bridge) - 4GB RAM
  2. RaspBerry Pi 2 Model B 900MHz quad-core ARM Cortex-A7 CPU - 1GB RAM

Sample file: 60s sample from the movie Alatriste (2006). The original file is 1080p and takes 30MB. I transcoded the file to 720p. All audio tracks were ignored to concentrate the study on video transcoding.

Results:

On (1), using Handbrake (x264 codec) I transcoded with x264-settings veryslow and average bitrate 1145kbps (1-pass) which resulted in a 7.7MB file. Profile High, level 4.0. The encoding took 3min 36s using 4 threads. Total cumulated CPU charge of handbrake ~ 380%. Video quality was very good. Little artifacts could be observed and loss of detail not easily observable. See still below.

On (2), using GStreamer and omxh264enc (hardware accelerated) I transcoded with target-bitrate=1145000 (1145kbps), control-rate=1 (variable bitrate control method) which resulted in a 6.9MB file. The encoding took 7min 4s using 1 thread. Total cumulated CPU charge of gst-launch-1.0 ~ 100%. Video quality was noticeably degraded with artifacts clearly visible and easily observable loss of detail. See still below.

gst-launch-1.0 -v filesrc location=sample-1080p.mp4 ! decodebin ! videoconvert ! \
videoscale ! video/x-raw,width=1280,height=688 ! omxh264enc control-rate=1 \
target-bitrate=1145000 ! h264parse ! mp4mux ! \
filesink location=sample-720p-OMX-1145kbps.mp4

When using GStreamer with x264enc as encoder, the total cumulated CPU charge of gst-launch-1.0 goes to about 380%, which supports the fact that omxh264enc actually uses the GPU. Also, with x264enc in (2), time goes beyond 15min.

Conclusion:

For a fairly similar file size, the time spent by the hardware-accelerated RaspBerry Pi 2 GPU encoder was almost twice as that of the software x264 encoder on a dual core i7-2620M. Adding up audio transcoding and multiplexing could close a bit this gap due to the largely unused CPU on the RaspBerry Pi during this test. Video quality was clearly superior on the software-encoded file. See stills below.

Available configuration options for omxh264enc (exposed by gst-inspect-1.0) are limited compared to the x264 encoder but further experimentation could provide better quality.

Annex:

Installation of GStreamer and OpenMax from Raspbian repositories:

$ apt-get install libgstreamer1.0-0 libgstreamer1.0-0-dbg libgstreamer1.0-dev liborc-0.4-0 liborc-0.4-0-dbg liborc-0.4-dev liborc-0.4-doc gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gstreamer1.0-alsa gstreamer1.0-doc gstreamer1.0-omx gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad-dbg gstreamer1.0-plugins-bad-doc gstreamer1.0-plugins-base gstreamer1.0-plugins-base-apps gstreamer1.0-plugins-base-dbg gstreamer1.0-plugins-base-doc gstreamer1.0-plugins-good gstreamer1.0-plugins-good-dbg gstreamer1.0-plugins-good-doc gstreamer1.0-plugins-ugly gstreamer1.0-plugins-ugly-dbg gstreamer1.0-plugins-ugly-doc gstreamer1.0-pulseaudio gstreamer1.0-tools gstreamer1.0-x libgstreamer-plugins-bad1.0-0 libgstreamer-plugins-bad1.0-dev libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.2.0
GStreamer 1.2.0

QuickTime X still of 720p video transcoded using HandBrake (x264) on a MacBook Pro (open or download image for the full detail):

QuickTime X still of 720p video transcoded using HandBrake (x264) on a MacBook Pro

QuickTime X still of 720p video transcoded using GStreamer (hardware encoding through OpenMAX) on a Raspberry Pi 2 (open or download image for the full detail):

QuickTime X still of 720p video transcoded using GStreamer (hardware encoding through OpenMAX) on a Raspberry Pi 2

Update:

Following ecc29's suggestion of using lanczos scaling method I performed a test adding method=lanczos to videoscale. The encoding process doubled in time, jumping from about 7min to 14min 37s. The result is almost equal in quality to that without method (default bilinear). Indeed, the defects mainly come from the encoding process in hardware. They are clearly compression artifacts.

Improve this answer
5
  • For the image quality after GStreamer transcoding, another factor should be considered. Different parameters for videoscale will have influence on the image before gstreamer send it to omxh264enc. Videoscale uses bilinear as default option. Lanczos is better but it's too slow. The developers of gstreamer are working on more options for videoscale, but they are not in the stable release yet. Some generated patterns may be helpful to compare different options:
    – ecc29
    Apr 16, 2015 at 16:17
  • gst-launch-1.0 -e videotestsrc pattern=zone-plate kx2=80 ky2=45 num-buffers=1 ! video/x-raw, width=1920, height=1080 ! videoconvert ! videoscale method=lanczos ! video/x-raw, width=1280, height=720 ! avimux ! filesink location=lanczos_1280.avi
    – ecc29
    Apr 16, 2015 at 16:17
  • I've updated the post with the results of the lanczos scaling method.
    – M. Rubio-Roy
    Apr 18, 2015 at 11:38
  • Thinking about buying 3 b+. Any update 3 and a half years later? Real-time encoding possible now?
    – akostadinov
    Jan 19, 2019 at 18:54
  • If you care about competitive bitrate at all omxh264enc's quality is almost unusably bad vs libx264's faster preset. It would be interresting to compare their respective vmaf score at same bitrate. But for now since I can spare the extra CPU cycles I will keep using software encodes on a RPi 4.
    – user643011
    Oct 19, 2021 at 9:38
1

The GPU in the RPi is pretty beefy. I've read that in terms of encoding you can encode 1080p@30fps. Also encoding multiple streams is also possible. It's also believed that you could encode vidoes on the fly using the RPi.

But. Modern day graphics cards have the capability to run the whole encode on the GPU, which is what a GPU is really good at.

If I had to gauge a personal opinion. It would be that the RPi would not be faster than a medium spec graphics card. But I think that it would be a lot faster than you think. Maybe even near 75% the speed.

I could not find a comparison available anywhere.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.