(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #14)
- Hardware decoding/acceleration: org.freedesktop.Platform.ffmpeg-full seems to provide support for VAAPI hardware decoding, but that's an experimental, unfinished and disabled feature of Firefox' disabled native wayland backend (bug 1622425/bug 1610199/bug 1587060/bug 1543600). X11 VAAPI is tracked in bug 1619523, but RedHat is only interested in the Wayland implementation, as it's used by default in Fedora. Both require OpenGL rendering (gfx.webrender.all), but currently it's only enabled on Nightly (bug 1614523/bug 1491303). Software rendering is used by default.
- Software decoding: It seems the same OpenH264 (Cisco's binary blob) would be used. Or, ... are you already using ffmpeg-full? Or is Firefox currently using its OpenH264 Gecko Media Plugin - I thought it was only used for WebRTC, but I don't know? Maybe Flatpak is just inferior to regular Linux packages in terms of enabling proprietary codecs. If there is no other solution, Mozilla had an incentive to drive bug 1619523 faster forward.
To be honest, this exceeds my knowledge so I can only answer to the release automation-related bits.
- Release strategy: Why has Firefox Stable been released on Flathub without having released Nightly first, so that changes could be tested the next day?
Looking back, that would've made the road less bumpy, I agree. When we first looked into this, our automation for nightly vs release was different and Flathub was still in its early stages and had no variety of channels (beta/stable) to push to, if I recall correctly. So we simplified the usecases, started building this for Firefox release, tested against their staging Flathub instance and then proceeded for the production instance. Both our automation and Flathub have grown, ever since, more mature, so now I think we'd be able to publish more products (ideally with different app ids).