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:
- MacBook Pro (Early 2011) dual-core i7-2620M 2.7GHz (Sandy Bridge) - 4GB RAM
- 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.
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 ! \
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.
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.
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
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 GStreamer (hardware encoding through OpenMAX) on a Raspberry Pi 2 (open or download image for the full detail):
Following ecc29's suggestion of using lanczos scaling method I performed a test adding
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.