#1

Hey all,

I wanted to make a thread on codecs and general overlays that increase the overall functionality of the OS.

Particularly I don’t know how I’d get by without ffmpeg, practically all web videos use it. But also a package like libva provides hardware acceleration and can theoretically directly affect the multimedia experience users have.

Please let me know if you have some essential overlays of your own and also if you have any input on why some of these are not included by default. The obvious reason is space but some of the packages’ benefits seem like they would be worth it anyway.

I look forward to the discussion :slight_smile: My list:

  • apache-commons-codec
  • dav1d
  • ffmpeg
  • flac
  • gstreamer1-libav
  • gstreamer1-plugin-openh264
  • gstreamer1-plugins-bad-free-extras
  • gstreamer1-plugins-base-tools
  • gstreamer1-plugins-good-extras
  • gstreamer1-plugins-good-gtk
  • gstreamer1-plugins-ugly-free
  • gstreamer1-svt-av1
  • gstreamer1-svt-vp9
  • gstreamer1-vaapi
  • java-latest-openjdk
  • lbzip2-utils
  • libdav1d
  • libdvdcss
  • libva
  • libva-utils
  • libva-vdpau-driver
  • libvdpau
  • libvdpau-va-gl
  • libvpx-utils
  • mesa-libGLU.x86_64
  • mesa-libOSMesa.x86_64
  • mesa-libOpenCL.x86_64
  • mesa-libd3d.x86_64
  • mesa-vdpau-drivers.x86_64
  • openh264
  • openjpeg-libs
  • opus-tools
  • p7zip
  • p7zip-doc
  • p7zip-gui
  • p7zip-plugins
  • pipewire-gstreamer
  • sbc
  • svt-av1
  • svt-av1-libs
  • svt-vp9
  • svt-vp9-libs
  • vdpauinfo
  • vorbis-tools
  • vulkan-headers.noarch
  • vulkan-tools
  • vulkan-validation-layers.x86_64
  • zstd
#2

One other thing I forgot to mention is that there are actually flatpak versions of ffmpeg, libva, and openh264 as well (and of course I have them installed). Not sure of how they overlap with the system packages though.

org.freedesktop.Platform.VAAPI.Intel
org.freedesktop.Platform.VAAPI.Intel.i386
org.freedesktop.Platform.ffmpeg
org.freedesktop.Platform.ffmpeg-full
org.freedesktop.Platform.openh264

Flatpaks and media codecs
#3

Whenever someone ask me about codecs I just tell them to install ffmpeg-libs from rpmfusion for codecs for the host. I also have this post about the topic.

#4

I think the idea with Silverblue is to keep the base system as minimal as possible so that it is stable and easier to test. In previous versions of Silverblue I would always need to overlay ffmpeg to get Firefox to work on YouTube effectively. Now the Flatpak for Firefox brings the codecs in with it. That is the general direction that Flatpak apps should be going for codecs and other library dependencies IMO. So it is a balance between Fedora policy, licensing, legal restrictions, and utility that will determine what is included in the base system.

#5

That was what I thought would be the case when I first started with Silverblue, but the Firefox Flatpak in the Fedora remote does not handle codecs well. I know the Flathub one apparently does, but the fact they behave differently bothers me.

It appears to me to be on a per application basis, is that right? If so that does not seem very efficient.

#6

I think the codec support in Flatpak apps is still evolving and getting better all the time which is a good thing. The org.freedesktop.Platform.ffmpeg-full runtime flatpak is working pretty well now. I do not see any issues for audio/video playback with the Fedora Firefox flatpak now, so I don’t know what you mean that it does not handle codecs well. In any case, I still believe that because there are solutions like the ffmpeg runtime flatpak, the need for an overlay ffmpeg package will eventually go away.

#7

Are you sure you have the Firefox from the Fedora remote or the Flathub remote? Because it has been more than just me to notice regarding the one in the Fedora remote. This is what I see when I try to stream a video on ESPN.com for example:

video_not_supported
video_not_supported1604×736 60.1 KB

I know it might be considered kind of anal but I was told previously that if I were to bring up any issues regarding Firefox Flatpak to make sure it was the one from the Fedora remote.

I’m having a lot of issues with that Flatpak, but if I could solve just one it would be the codecs. And the best solution would be for the codecs to be included as a Flatpak runtime, like you mentioned, but it needs to be accessible by all the others too.

#8

You are right, I had the Flathub Firefox installed. For now I would recommend to do not use the Fedora Firefox flatpak. I don’t know why Fedora does not enable the dependency to the ffmpeg-full flatpak or at least make it possible for the user to enable it after it is installed. This is a bad user experience IMO.

1 Like
#9

Ah well, this gives me some added motivation to participate in Test Week. I’ll just blow away this system and start anew, this time without a ton of overlays.

I was thinking about participating with Jupiter Broadcasting, I’m pretty sure they are getting something organized to help out noobs for Fedora’s Test Week. Said they will help us learn to file quality bugs which are actually helpful.

#10

Generally I find the whole process of layering RPM’s from rpm fusion tedious and a nuisance when rebasing so I keep only ffmpeg-libs installed to make video work.

As I think about it I should script this process similarly like I have setting up toolbox as a 20-line bash script.

The reasoning behind pushing flatpaks is unclear to me. Having trusted software installed on the base os is far more convenient because the sandboxing often gets in the way and I had to juggle around files to get them opened with, say, Inkscape. Don’t get me even started on the cancer UX with sandboxed VS Code…

When I was figuring stuff out I even tried running gui apps in toolbox - it’s only viable if you use the default theme and it will install a metric ton of additional packages to get wayland working. Not sure how good it is to do that given that it will use the base system dotfiles.

All in all I’m dual booting with Windows because I had to do some e2e test writing and it just works on Windows while on Fedora it failed for me completely. Also my team socializes online by playing games and most of them run better on Windows.

I would switch if Windows wouldn’t be so damn slow.

#11

One of the reasons people push for, say, firefox flatpak is because you don’t need to layer codecs anymore.

As another example, why people prefer the discord flatpak? because it is easier to push a update to flathub than to any disto repository, the rpm was outdated an unusable for a few days the last time there was an update, on flatpak it was updated in ~5 minutes. Now consider that you need people pushing updates to ALL repos from all distros vs just 1 single line of code change for flathub.

On the other hand tools like vscode, vim or emacs should be used in a toolbox. Yes, you have to layer hundred, if not thousands, of packages, but it is the only way that makes sense, and the only one that actually works for many specific usecases.

When I was figuring stuff out I even tried running gui apps in toolbox - it’s only viable if you use the default theme

You can install gnomes-themes-extras or something like that to use adwaita-dark for example, it will use the host’s config.

#12

You can install gnomes-themes-extras

Did that but there were some inconsistencies which I can’t recall now. Possibly issues stemming from using Gnome Tweaks? I’ll try extending my toolbox building script to setup VS Code too.

I searched for how to get a .desktop shortcut for a toolbox app and found my issue: the fonts were extra-wide and I was unable to google it. Setting up VS Code in toolbox then already took me hours and I had it available one reboot to windows && git up && yarn && yarn e2e:local away. Hopefully chromium will spawn in a non-headless mode properly when ran from the toolbox :).

As I’m already derailing this thread I’ll drop in that I had strange 1-3s freeze-ups from time to time. Got enough RAM (32GB) and weren’t near using even a half of it. No considerable load on the CPU. I’m on a Thinkpad E590 and I suspect it throttled due to thermals but I wasn’t able to verify that. journalctl also gave no hints as to what could be responsible. I upgraded to 32 recently and I’ll check if it still occurs.

#13

I was misguided in my original post and topic. I thought overlays were needed for media on Firefox to work properly but it turned out I just needed a few tweaks (use Flathub FF and then hard set it for Wayland; see thread on dropping FF from base image).

Now I have one overlay which is gnome-tweaks, and that is only because 1.5 font scaling is perfect for my laptop display (not sure if there is a better way for that). All of my media on the FF flatpak runs perfect.

#14

We learn as we go. Took me a while to understand the Silverblue concept too.

Key thing to remember: Everything that runs as a Flatpak is completely containerized and runs fully sandboxed from the host OS. So if a Flatpak’ed application is missing a codec then that needs to be fixed in Flatpak, either by adding it to its base image or by adding a plugin.

Adding codec RPM packages to the overlay will only add support to the host OS.

Example: If you’re using the preinstalled Firefox, you can add support by adding RPM’s to the overlay. If you use Firefox as a Flatpak (either from Fedora Registry or Flatpak) then it needs a better build or a plugin.

The general notion behind Silverblue is of course that we keep the host OS as thin as possible, and manage applications using Flatpak. So try to refrain from adding overlays as much as possible.

1 Like
#15

I wonder if gstreamer or ffmpeg (along with their apps) can be modified to also look for plugins in non standard locations and load the flatpak extensions that have been made for various codecs.

We can then have a version of something like codeina that doesnt rely on rpm/deb.