Compiling ffmpeg with Raspberry Pi hardware acceleration
AFAIK the regular Debian/Raspbian version of ffmpeg does not support Raspberry Pi's hardware H.264 acceleration, so I decided to roll my own. Compiling also avoided some bloaty dependencies that the package in the Debian (Jessie backports) repository has.
It's a good idea to use checkinstall so that a proper deb package is created and installed. Raspbian should have git and compilation tools installed by default, but if not, install them. Then follow these steps:
- Install checkinstall if you already haven't
sudo apt install checkinstall
- Remove any other ffmpeg package
sudo apt remove ffmpeg
- Get the ffmpeg source code and compile it (this will take loooong)
git clone https://github.com/FFmpeg/FFmpeg.git
cd FFmpeg
./configure --arch=armel --target-os=linux --enable-gpl --enable-omx --enable-omx-rpi --enable-nonfree --enable-mmal
make
(on Pi 2/3 you can utilize additional CPU cores withmake -j4
)- Install the self-compiled ffmpeg (fill in any information checkinstall wants)
sudo checkinstall
echo "ffmpeg hold" | sudo dpkg --set-selections
Done!
You now have the latest and greatest ffmpeg installed and there's a precompiled deb package in your FFmpeg directory (you can delete the other stuff to free some space). Store that in a safe place, so you can quickly install it on another Pi (sudo dpkg -i ffmpeg*.deb
) without recompiling.
If a future ffmpeg version offers something new that you need, you can simply repeat these steps to upgrade.
As ffmpeg is now installed like a regular Debian package, it's easy to uninstall:
sudo apt remove ffmpeg
I'll be assuming this ffmpeg variant in my future Raspberry Pi projects and tutorials, so if you can't get them to work, switch to this self-compiled version.
Usage
To take advantage of Pi's accelerated H.264, use ffmpeg option-c:v h264_mmal
for decoding and -c:v h264_omx
for encoding. If you have a H.264 video file (inputfile.mp4) that needs to be re-encoded to a smaller bitrate (1500k), for example, you can take advantage of both:
ffmpeg -c:v h264_mmal -i inputfile.mp4 -c:v h264_omx -c:a copy -b:v 1500k outputfile.mp4
This took an entire day to compile on an A+, but it did work. And thanks for the checkinstall tip.
ReplyDeleteWhy doesn't some organization just host the compiled binary?
I'm having difficulty controlling the output quality. I've gotten used to -preset and -crf which doesn't work here. There's -profile:v which seems to take a number and doesn't help. So far -b:v works best, but I need to go as high as 5000 to match -preset medium -crf 23.
Good to hear about your success!
ReplyDeleteIt'd be nice if Pi Foundation had a proper Debian repository for optional Pi-accelerated software versions, but I guess they're too busy. Precompiled binaries are frowned upon and may indeed contain old or even malicious code, so I guess it's best that people don't build a habit of downloading them from untrusted places – IoT security flaws are nightmarish already :D
IIRC the Pi H.264 hardware doesn't support all the encoding features that software encoders have, so ffmpeg probably just ignores some. Even at high bitrates H.264 still saves tons of space, so the hardware encoder is a blessing for real-time camera applications and such.
You don't really solve the security issues by requiring users to download the source. How do you know the source wasn't tampered with? Does anyone really go through all the millions of lines of code to check?
ReplyDeleteThis isn't some obscure app; there's a significant degree of interest from users around the world. All we need is for some trusted "authority" to host a vetted binary. Meanwhile, hosting binaries may be frowned upon in the Linux world, but it's de rigeuer in every other context. Got a smart phone? Got apps on it? Perhaps from Apple or Google Play? Hosted binaries!
Thanks again for your post!
Well, this subject of software reliability is mainly philosophical and somewhat off-topic, but I understand why the FOSS scene wants to avoid the pitfalls of app store jungles and shady middleman binary distributors, and so far it has worked well. On git systems (esp. GitHub) every line of code is traceable to a person and often needs approval from a project lead (not to mention downstream package/distro maintainers, testers, etc.), so anyone writing bad code will quickly get kicked out of a significant project like FFmpeg, losing all credibility. So yeah, compiling code from an original source repository is quite secure.
DeleteIf there's truly lots of demand for a Pi-specific FFmpeg package, someone could volunteer to become a package maintainer for the Raspbian repository; in this case it shouldn't even be hard as instead of patching it's just a matter of adding some compiler options. Then everyone could use it with a simple apt install. Hardkernel does this for their Odroid devices, providing out-of-the-box HEVC/H.265 acceleration for their Ubuntu releases, for example.
I have built the ffmpeg deb package with Hardware Acceleration as per this article
ReplyDeleteHope it will be helpful for some one.
Download Link: https://www.dropbox.com/s/pktsbt5u4n5i78b/ffmpeg_20181121-1_armhf.deb?dl=0
Install command: sudo dpkg -i ffmpeg_20181121-1_armhf.deb
Raspberry Pi 3 B+
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch