I believe we currently package org.freedesktop.Platform.openh264 and use some ffmpeg shims to get our flatpak builds to support h264 playback by default. However, because the openh264 decoder is not as optimized as ffmpeg, users suffer poor performance and occasional decoder failures.

Users are able to install the ffmpeg-full extension to enable a better performing decode, but my understanding is we cannot do this by default due to licensing concerns around h264 and other decoders.

Our non-flatpak Linux builds do not provide a h264 playback mechanism by default, and will fail unless a local version of ffmpeg is found. Would it be worthwhile to do this for the flatpak builds also? It would provide more consistency between different Linux builds, and would avoid the issue of users getting stuck in the less optimal playback case.

I vaguely remember us doing this on purpose, but maybe I'm thinking of something different.

Do we know for sure that installing ffmpeg-full will work in the flatpak due to sandboxing?

My understanding is that installing ffmpeg-full works (bug 1667038, bug 1735013), but it's licensing concerns that stop us doing so.

I assume ffmpeg is installed by default for most Linux users. There is a checkbox in the Ubuntu setup process.
I think the licensing aspect is why Ubuntu and not Mozilla packages the Firefox snap.

(In reply to Darkspirit from comment #3)

I assume ffmpeg is installed by default for most Linux users. There is a checkbox in the Ubuntu setup process.

Even if that's the case (which it is not for non-Ubuntu distributions): Shouldn't the flatpak package of firefox behave identical on all linux distributions regardless of their packaging policies?
And (but I'm not quite sure about the following point): Can the flatpak package of firefox even use the local ffmpeg installation? If so, what would be the point of using a sandbox if your applications uses the system-wide libraries and packages anyway?

Bug 1679274 comment 9 is another good summary.

The key question here I guess is whether openh264 is providing sufficient benefit in some cases that the benefit justifies the confusion.
Bug 1784393 is another report of videos that seem to play but are corrupt.

Perhaps there may be some middle ground:

• Could/should we limit the use of openh264 to some subset of h264 video for which we expect it will decode correctly?
• Do we already return "maybe" from canPlayType() when we don't know whether openh264 will succeed?

OpenH264 2.3 fixes all the playback stutter issues that I've seen. If there are other videos that still stutter I think we should be able to fix or get the problem fixed in upstream OpenH264 and try to get it deployed.

The current flatpak version of firefox bundles the version 1.8.1.2 of OpenH264. Are there already plans for the update of OpenH264 to version 2.3?

The version of OpenH264 that Firefox uses for WebRTC (1.8.1.2) is not what Firefox will use for regular video decoding. That is done via the flatpak ffmpeg/OpenH264 that's part of the freedesktop-sdk