Created attachment 1998709 [details] screenshot of failure Created attachment 1998709 [details] screenshot of failure Description of problem: Fedora shipped chromium is unable to play live streams from twitch.tv. Firefox can play them fine. This appears to be some limitation with ffmpeg-free, as swapping to rpfusion ffmpeg allows twitch.tv streams to play fine. This does not appear to be the same bug as https://bugzilla.redhat.com/show_bug.cgi?id=2240127. I applied the ffmpeg side patch from that bug: https://bugzilla.redhat.com/show_bug.cgi?id=2240127#c9 and rebuilt ffmpeg, and also reverted the chromium related side patch: https://bugzilla.redhat.com/show_bug.cgi?id=2240127#c6 and rebuilt chromium, and after doing so playback still failed.
Additional note: ffmpeg by itself is also able to play the stream. On firefox open any twitch stream. Right click on the page and click inspect. Click the network tag. search for m3u8. You will find a url for an m3u8 file like so: https://video-weaver.arn04.hls.ttvnw.net/v1/playlist/CqsG3UPr4U6yjRDg648SM4LstZ2AHOgRbwCMCkYUFPLwD8t3qht8O0EcHIbZfdeO6mboox6aeNNlnyLh0SBtmWaafNrBvwuraIk3fmt1UQE2LLwaMWL5_CbfrRdcxbY3wdOja8x2UCnzmlzN8rfCbocRJYMgZylp8IRJFDYoC5i4KGd3w7QMjXmP7T6ETDFjsEU14ADjYmtHQB0pqoEADne8xdM1DzhVdIcSmGYkmYjYpreuelJRbX1wPAG2qZeraDeepJ7tgbU77K-ox38B0vpTDtGguSNRrKXGDGQNozAb56ZaEz_XOZA2ZsagiszcO95RXiWX_ox2zgp4NM2DwJuOPNei5zfJ1jw7e9vZ9TtgocQa4cpCptQ5fP7O3Lu8VPIp_w-DEbtYGohIs0Egi9w4OXHL43QScOmLmnRxH9ECVYNYrG89w4fdcp6er7mh39ZKBqT6CUY-m3XnS2Nxzysiq-AZSegJUPMrLSN1rgUkmdQolRtZnq_82UaVBMDMX6QtpwmE87BkEHVks299LtMHSvsRxhMBaRDznAllKCHG6EYxnGGMZApX6CtRyEdLjgOOaFiTaLd5R56FmhaYT-2zplGRY9atTTerns_4Fd8bcM0i1zOLUlN6iMhyKweWyWy1XXdgqUsBbQcZUCtEFcu3Mh09jCihJAkkdqJpuRb95cYKoCPXffvf0rm-Fn-n4EtyhV1A5OYkopkeZIC-4RMmSidsT8O9Dwa2Q16U6JwvrFQZM4rJdWZnW1JLnL1YNyVatTtj-Ix8chpq4U7L7E-1mATQHpyh0WRYi_c5wVYbfzNPWp4EBom8vYk9Y4WApxXcoUcWdC-Wzyqy-DbzDyblvK9awdHtsYt-SFFO8klR2XJ1bosaB4JH7KQWQNGc9vdM0HJZZd9bcAuYYF8kgsGur8N_rc-17Im5x811EnojcAjSzI19VSSwANcarLyzNRlGFz__W4kPmD2vhy1nPr2QI5sqXUnJoV0KKocV-bztuJAM_FF3rsdWuP_LTH9ZUqgugW132kWR0TZSTK-ANHeWhUqpZV8x5cIrTNpEwKUzDSQJfECsatJ8YmuKOxoMkU7kopyc6Omitv89IAEqCXVzLXdlc3QtMjD9Bw.m3u8 Now open a terminal and type ffplay <theurl> This works perfectly fine with the fedora shipped ffmpeg-free, so I'm not sure why it's not working inside fedora shipped chromium.
It's because the chromium sandbox currently blocks dlopen() for the openh264 library. Kalev Lember and I have started working on a plan to fix this by switching to building ffmpeg against a stub openh264 library so that the linking is "correct" for Chromium. This also will allow us to correctly link Chromium, FreeRDP, and many other things directly to OpenH264. It's in progress, don't worry. We got this! :)
Thanks for the info on this, it's been driving me nuts. Fwiw after you provided the info I did find https://src.fedoraproject.org/rpms/chromium/pull-request/29 which supposedly updates the chromium side to allow dlopen on openh264 from my understanding, however after rebasing the patches there and recompiling I still did not have any luck. Regardless if it can be fixed on the ffmpeg side with your approach for multiple applications rather than on each application side (such as rebuilding chromium.. ugh), that's a much better approach.
Once Kalev gets noopenh264 shipped in stable Fedora releases and EPEL 9, we can start updating everything to use it. One more rebuild of Chromium et al will be required, but after that, we will be gucci. :)
Awesome to hear. Thanks again. I found the noopenh264 pending package and managed to build it + swap the ffmpeg libopenh264 dlopen patch with the noopenh264 implementation. It's working now except the video is a little bit stuttery in chromium. IS there a link anywhere for what's needed for patching in chromium? Apologies for being persistent on this, I know I'm just being impatient here at this point. Glad to see work being done on it.
fwiw the stutter also occurs if I compile ffmpeg with openh264 + openh264-devel directly. that being said -- would it be a viable idea to repackage ffmpeg in the same format as rpmfusion (ffmpeg, ffmpeg-devel) so that they are easily swappable and can be marked on the rpmfusion version as Obsoletes? essentially the same thing planned for noopenh264. This way if users enable rpmfusion repo the codecs will get fixed via automatic update -- therefore not coming from fedora repos or fedora install media.
rpmfusion (ffmpeg, ffmpeg-libs, ffmpeg-devel) **
They asked us not to, so we didn't. That said, as long as you don't explicitly ask for it, it's fine. And you can overlay rpmfusion's libavcodec on Fedora's ffmpeg by installing libavcodec-freeworld.
I have another proposal that may work then: In the Fedora side ffmpeg, change all: Requires: libavcodec-free... to Recommends: libavcodec-free... (except the devel packages) This breaks the hard dependency of ffmpeg-free and it's supplementary packages on libavcodec-free, and would allow rpmfusion's side to replace it if the repo is enabled without fedora and/or the user calling it directly. To be done from rpmfusion side: Provides: libavcodec-free = %{?epoch:%{epoch}:}%{version}-%{release} Enhances: %{name}-free Obsoletes: libavcodec-free Technically the same way they did it with mesa-freeworld packages (mesa-va-drivers -> mesa-va-drivers-freeworld, mesa-vdpau-drivers -> mesa-vdpau-drivers-freeworld), and the same way planned for noopenh264->openh264. Again, this provides a seamless update for the user if the repo is enabled without requiring Fedora to ship or call 3rd party packages directly. Not only that but it also compensates for versioning differences between rpmfusion and Fedora, allowing breathing room for patching on the rpmfusion side in case something needs to be added after a release has been made (such as the chromium patch for https://bugzilla.redhat.com/show_bug.cgi?id=2240127) I've tested this on Nobara and it works well: ffmpeg-free build: https://copr.fedorainfracloud.org/coprs/gloriouseggroll/nobara/build/6630604/ ffmpeg (rpmfusion) build: https://nobaraproject.org/repo/nobara/appstream/38/x86_64/f/ sudo dnf update --refresh: Installing dependencies: libavcodec-freeworld x86_64 6.0.1-3.fc38 nobara-appstream 4.8 M replacing libavcodec-free.x86_64 6.0.1-1.fc38
We (rpmfusion team, but it's also shared by many experienced fedora package maintainers) do not want to automatically replace $distro packages as it's against our policy to do so. The reason is despite a fully enabled ffmpeg is the primary reason end-users want rpmfusion-free, we can't assume this choice is neither permanent nor mandatory. Anyone could temporarily rely on using fedora's ffmpeg-free and rely on few rpmfusion-free packages for related or even totally use-case. Using that at the packaging level would enforces that on any update from end-users. Please do not break this convention in any downstream usage. That's said improving the install process would be easy as using "dnf group update multimedia"
(In reply to Nicolas Chauvet (kwizart) from comment #10) > We (rpmfusion team, but it's also shared by many experienced fedora package > maintainers) do not want to automatically replace $distro packages as it's > against our policy to do so. > The reason is despite a fully enabled ffmpeg is the primary reason end-users > want rpmfusion-free, we can't assume this choice is neither permanent nor > mandatory. > > Anyone could temporarily rely on using fedora's ffmpeg-free and rely on few > rpmfusion-free packages for related or even totally use-case. > Using that at the packaging level would enforces that on any update from > end-users. > Please do not break this convention in any downstream usage. > > That's said improving the install process would be easy as using "dnf group > update multimedia" "dnf group update multimedia" Does not work because ffmpeg-free and ffmpeg are two separate packages, one does not replace the other, and ffmpeg-free has a hard dependency on its supplemental packages, therefore you hit conflicts with both ffmpeg vs ffmpeg-free and ffmpeg-libs vs all of the ffmpeg-free subpackages. Ex: package ffmpeg-6.0-11.fc38.x86_64 from rpmfusion-free-updates conflicts with ffmpeg-free provided by ffmpeg-free-6.0.1-1.fc38.x86_64 from updates - conflicting requests - package ffmpeg-6.0-11.fc38.x86_64 from rpmfusion-free-updates conflicts with ffmpeg-free provided by ffmpeg-free-6.0.1-1.fc38.x86_64 from @System - package ffmpeg-6.0-11.fc38.x86_64 from rpmfusion-free-updates conflicts with ffmpeg-free provided by ffmpeg-free-6.0-2.fc38.x86_64 from fedora - package ffmpeg-6.0-11.fc38.x86_64 from rpmfusion-free-updates conflicts with ffmpeg-free provided by ffmpeg-free-6.0-5.fc38.x86_64 from updates - package ffmpeg-6.0-11.fc38.x86_64 from rpmfusion-free-updates conflicts with ffmpeg-free provided by ffmpeg-free-6.0.1-1.fc38.x86_64 from updates - conflicting requests - problem with installed package libavformat-free-6.0.1-1.fc38.x86_64 - package ffmpeg-libs-6.0-6.fc38.x86_64 from rpmfusion-free conflicts with libavformat-free provided by libavformat-free-6.0.1-1.fc38.x86_64 from @System - package ffmpeg-libs-6.0-6.fc38.x86_64 from rpmfusion-free conflicts with libavformat-free provided by libavformat-free-6.0-2.fc38.x86_64 from fedora - package ffmpeg-libs-6.0-6.fc38.x86_64 from rpmfusion-free conflicts with libavformat-free provided by libavformat-free-6.0-5.fc38.x86_64 from updates - package ffmpeg-libs-6.0-6.fc38.x86_64 from rpmfusion-free conflicts with libavformat-free provided by libavformat-free-6.0.1-1.fc38.x86_64 from updates To further complicate things, when you install ffmpeg-free (as is done by the fedora installer), it pulls in all those hard dependency subpackages, and you can't do 'dnf swap ffmpeg-free ffmpeg' because again -- you hit a conflict with those subpackages, and you can't remove those subpackages without removing ffmpeg-free itself (and anything on the system that depends on it) unless you use 'rpm -e --nodeps' on ffmpeg-free and all of its subpackages.. which obviously isn't a good idea unless you absolutely know what you're doing.
Additional note: You can use 'dnf group update multimedia --exclude=ffmpeg,ffmpeg-libs' to work around this -- ideally if you want a smooth transition for users you'd want to remove these two packages and probably document somewhere how to switch to them if they want the full version.
fixup from previous comment: you'd want to remove these two packages from the multimedia group**
Easy to be fixed, we could both (fedora/rpmfusion) agree to have ffmpeg-bin virtual provides for both ffmpeg flavor and add the virtual provides deps in our comps. Will be fixed in rpmfusion rawhide "soon".
https://rpmfusion.org/CommonBugs#FFmpeg-free%20conflicts FYI our documentation explicitely stipulate: sudo dnf swap ffmpeg-free ffmpeg --allowerasing
Virtual names don't work properly in comps groups, so it doesn't help anything. An easy fix would also be that rpmfusion's comps group doesn't include ffmpeg-libs but instead includes libavcodec-freeworld (the overlay package) instead.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.