FFmpeg 3.0 and Firefox
Not long ago I blogged about Firefox being able to use FFmpeg directly. Since then, FFmpeg 3.0 has been released, with incompatible changes API and ABI-wise. I wasn’t sure about upgrading, but now the dust has settled and the strategy forward is clear.
I have several packages in my system that use FFmpeg, most notably mpv and MOC. mpv builds and runs with FFmpeg 3.0 just fine, and MOC needs a small code change that has already been committed to “trunk” in its Subversion repository.
However, Firefox dynamically loads FFmpeg when running and is currently bound to the API and ABI of FFmpeg 2.8. I’m not sure if it’s easy for Mozilla to support two FFmpeg ABIs simultaneously and a search on their bug trackers didn’t turn up any relevant results I could see about future FFmpeg 3.x support.
If you simply replace FFmpeg 2.8.6 with FFmpeg 3.0 in a given system, you will see Firefox refuses to load its libraries and the YouTube HTML5 video test page won’t show H.264 as available if you were relying on FFmpeg to provide that support.
I monitored what Arch Linux did in this regard because their Firefox package depended on FFmpeg. So far, they have chosen to make Firefox depend on a newly created “ffmpeg2.8” package which can be installed in parallel with “ffmpeg”, and using a simple ld.so.conf file to tell Firefox where to look for FFmpeg libraries. Note the FFmpeg project still supports branch 2.8 and it’s expected to receive security fixes for the time being.
I replicated that work in my SPEC files repository. FFmpeg 3.0 is built normally and FFmpeg 2.8.x creates a special “ffmpeg2.8” package. As you can see, this one is built with --disable-programs, --disable-doc, --disable-static, --disable-debug and --disable-filters. These flags make sure only the dynamic libraries and header files are installed as part of the package. In addition, libdir, shlibdir and incdir are configured so the files end up in a specific subdirectory instead of colliding with FFmpeg 3.0.
Finally, the package ships a file in /etc/ld.so.conf.d adding the directories /usr/lib64 and /usr/lib64/ffmpeg2.8. The second one is obvious and needed for the dynamic linker to find the FFmpeg 2.8.x libraries when Firefox requests them. The first one just makes sure /usr/lib64 is chosen first as the source of the libraries without any version suffix, should any program need them.
This scheme will need to be supported until Mozilla ships FFmpeg 3.0 support directly in Firefox. Monitoring what Arch Linux does with their Firefox package is a good idea and will give you a rough estimate on when to deprecate and remove the specific “ffmpeg2.8” package.
Update: Support for FFmpeg 3.0 will land in Firefox 46, according to bug 1232268 and its related bugs. Firefox does ship support for several FFmpeg/LibAV binary versions at the same time, as you can easily observe in the FFmpegLibWrapper.cpp file.