OpenH264 Firefox support

slaanesh CentOS, Fedora, FFMpeg, Repositories

Fedora 24 has a new repository to enable OpenH264 decoding in Mozilla Firefox by enabling a specific repository. As described in the Wiki page, this is already available on newly installed systems.

As part of the packages contained in the Multimedia repository, there is also OpenH264 and support for it in both FFMpeg and Gstreamer Plugins. These packages conflict with the packages provided in the OpenH264 repository, so I’m now providing a custom build of the Mozilla integration along with FFMpeg and Gstreamer packages. This is due to the fact that:

  • I’m providing a more recent OpenH264 Gstreamer plugin as part of the “bad” package
  • I use slightly different names for the OpenH264 packages themselves
  • I’m providing Firefox H264 support also for CentOS and Red Hat Enterprise Linux

These new packages are already available now along with other small updates in other packages; so to install OpenH264 support for Firefox:

dnf/yum install mozilla-openh264

This work is also part of the Fedora 25 (rawhide) packages that I plan to publish next week (as time permits…) which will include OpenH264 1.6 and an FFMpeg with support for it along with other Nvidia enablements. FFMpeg support is finally for both encoding and decoding.

8 thoughts to “OpenH264 Firefox support”

  1. Not to hijack the thread but…

    Everyone should keep in mind that Firefox still does not have VDPAU hardware acceleration yet: https://bugzilla.mozilla.org/show_bug.cgi?id=1210729

    You *can* use VLC, but due to changes in FFMpeg 3.0 you cannot have hardware acceleration while running VLC multi-threaded. As a workaround I do:

    taskset -c 1 vlc

    If it works it should display:

    avcodec decoder: Using NVIDIA VDPAU Driver Shared Library 367.35 Mon Jul 11 22:43:02 PDT 2016 for hardware decoding

    Otherwise you’ll get an error about hardware acceleration disabled due to threads or something. There is an FFMpeg mailing list post floating around that discusses the change.

    If you are using VLC to view youtube, it WILL use the H246 codec instead of the WebM codec. OpenH246 support and eventual VDPAU support is long overdue, so kudos to everyone involved in the effort.

    Reply

    1. Thanks for the information. Do you have a mailing list link regarding the multithreaded VLC/FFMpeg interaction?

      Reply

      1. Here’s the claim from a VLC developer: https://forum.videolan.org/viewtopic.php?f=13&t=134770&p=445907&hilit=ffmpeg#p445907

        “It means you’re using FFmpeg, which no longer allows enabling hardware acceleration and threading at the same time. You need to use libav.”

        “This is decided while compiling VLC. You can’t change it at run-time.

        You can work-around the bug by disabling threading, but that will affect performance of unaccelerated video codecs.”

        “FFmpeg forbids combining multithreading and hardware acceleration. It’s not something VLC developers can consider; it’s all down to FFmpeg.”

        Then the FFMpeg patch I was talking about earlier: https://ffmpeg.org/pipermail/ffmpeg-cvslog/2015-October/094881.html

        avcodec: disallow hwaccel with frame threads

        HWAccels with frame threads are fundamentally flawed in avcodecs current
        design, and there are several known problems ranging from image corruption
        to driver crashes.

        Reply

        1. That’s really interesting, thanks. I tried on my system and works as described. Do you think it would be better to specify a single thread in FFMpeg by default? I mean at VLC compile time.

          I understand the implications of doing that. The streams that would benefit a lot from multithreading are H264, H265 and MPEG4; and since those would switch to hardware decoding, there’s not much else that can’t be decoded easily with 1 single CPU thread. What do you think?

          Reply

          1. I just discovered the “avcodec-threads” flag.

            vlc –avcodecs-thread=1 “https://www.youtube.com/watch?v=mQVLfelgjIk”

            This only affects the decoder.

            For transcoding, I’m assuming this is relevant (I do zero multimedia work, so caveat emptor):

            –sout-transcode-threads

            You could set it to single-threaded by default for minor convenience, as I imagine the power users can manually set the threads to “-1” for automatic.

          2. I’m about to upload a new VLC snapshot, I’ve tried on my system and it does enable VDPAU and hardware decoding even when the FFMpeg thread number is 0 (automatic, the default).
            Is that fixed? Can you confirm once you test the update?

Leave a Reply