On the fedora chromium package, some h.264 mp4s like the one linked fail to play and show the following in chrome://media-internals: 00:00:00.179 error "FFmpegDemuxer: unfixable negative timestamp." 00:00:00.180 error "FFmpegDemuxer: demuxer error: DEMUXER_ERROR_COULD_NOT_PARSE" The same video plays without error on flatpak chromium and chromium compiled from source. Reproducible: Always Steps to Reproduce: 1. Open chromium installed from fedora repos 2. Open the linked video 3. Observe that the video fails to play and the error in media-internals Actual Results: Video does not play, error in media-internals Expected Results: Video plays properly Version 117.0.5938.88 (Official Build) Fedora Project (64-bit)
The video link: https://v16m-default.akamaized.net/c43a7caa59fb4b1269406023358c7c94/650ce93a/video/tos/useast2a/tos-useast2a-pve-0068/o4CEogzMNEylfcZsMkNAILYznIJVtVCLAhgM2I/?a=0&ch=0&cr=0&dr=0&lr=all&cd=0%7C0%7C0%7C0&cv=1&br=856&bt=428&bti=OUBzOTg7QGo0NzZAL3AjLTAzYCM1NTNg&cs=0&ds=6&ft=iJOG.y7oZzv0PD1dK5hxg9w7jgMrBEeC~&mime_type=video_mp4&qs=4&rc=Mzo3NzUzN2k0Z2Y8ZmlpZUBpMzxnazs6ZmZlbjMzNzczM0AxY180XjMzXzYxYTE0Ni4uYSMzZi4ycjQwYC5gLS1kMTZzcw%3D%3D&l=20230921190858A59A973F21EF89007CB6&btag=e00088000
Additional details: I have rpmfusion ffmpeg installed and -freeworld packages. $ rpm -qa | grep freeworld mesa-va-drivers-freeworld-23.1.7-1.fc38.x86_64 libavcodec-freeworld-6.0-11.fc38.x86_64 gstreamer1-plugins-bad-freeworld-1.22.5-1.fc38.x86_64 libheif-freeworld-1.16.2-1.fc38.x86_64 $ rpm -qa | grep ffmpeg ffmpegthumbs-23.04.3-2.fc38.x86_64 ffmpeg-libs-6.0-11.fc38.x86_64 ffmpeg-6.0-11.fc38.x86_64 ffmpegthumbnailer-2.2.3-0.4.20210902gitd92e191.fc38.x86_64
Created attachment 1991257 [details] affectedvideo
Attached a video since the prior link is no longer valid
Same problem with most embedded OGG sounds Used https://freetestdata.com/wp-content/uploads/2021/09/Free_Test_Data_100KB_OGG.ogg to test
Hi Neal, it seems the problem is caused by the ffmpeg-first_dts.patch which is required for the system ffmpeg. it should work if we revert the change and use the non-upstream function av_stream_get_first_dts(). Of course it will breaks the compatibility with system ffmpeg 6.x. Info: Qt upstream already reverted change made. https://bugreports.qt.io/browse/QTBUG-110749
It looks like upstream is aware of this: https://bugs.chromium.org/p/chromium/issues/detail?id=1306560
*** Bug 2224141 has been marked as a duplicate of this bug. ***
I originally had the patch on ffmpeg and dropped it (see bug 2061392), and I could put it back, but there's a couple of issues with that: 1. RPM Fusion complained about it and refused to carry it in their build, so it was going to be a persistent ABI break between both. 2. I don't know if shipping it would reduce upstream's pressure to remove it. Or maybe they don't care, I don't know. That being said, if I shipped it again, then everything is "fine" as long as libavcodec-freeworld is used as an overlay library rather than swapping the full ffmpeg implementation. That's because the patch only touches libavformat. I guess we could also ask on the upstream bug report if there's been more progress getting rid of the need for the first_dts patch.
FWIW this affects anyone who wants to build anything chromium-containing for Fedora on the openSUSE Build Service (https://build.opensuse.org/). We are building Electron and four apps (bitwarden, element, signal, vscode). Three of these can potentially play videos. The lawyers do not allow building bundled ffmpeg, and Electron is not suitable for shipping in Fedora proper (or any non-rolling distro) due to upstream very short support period and frequent ABI breaks.
(In reply to Bruno Pitrus from comment #10) > FWIW this affects anyone who wants to build anything chromium-containing for > Fedora on the openSUSE Build Service (https://build.opensuse.org/). > > We are building Electron and four apps (bitwarden, element, signal, vscode). > Three of these can potentially play videos. > > The lawyers do not allow building bundled ffmpeg, and Electron is not > suitable for shipping in Fedora proper (or any non-rolling distro) due to > upstream very short support period and frequent ABI breaks. Shipping Electron in Fedora is probably fine if someone is willing to do it as a versioned package (similar to what's done for LLVM in Fedora). But fixing the usage of system ffmpeg is obviously required for this...
ABI breaks can be treated by versioning, yes (though the utility for end-users is questionable due to extreme bloat — I don't like what Arch does with it, for instance). But short support terms cannot. Electron 27 (released half a month ago) ends support around (extrapolating) April 2024. Fedora 39 (just released) ends support around (again extrapolating) around December 2024. That's 8 months of security patches for Chromium you would have to identify and backport. Add to that Node patches that i'm already getting bugreports about because upstream does not care to update their embedded Node copy. Now multiply all of the above by how many releases you decide to multiversion. (As a consolation prize, SOME of these are not critical for Electron due to not dealing with untrusted HTML/JS unlike a browser — but we still deal with untrusted images/videos) Maintaining one release at a time with the guarantee “these four apps work” and dropping ABI compatibility without warning, is something i can do in my free time. But if you decide to turn it into a fully supported OS runtime like node proper/java/python/etc (which arguably someone should, to hedge against upstream) it will quickly turn into a Qtwebengine-style mess of downstream patches that needs a full time job to maintain.
I am reintroducing the first_dts patch with ffmpeg-free-6.0.1. https://src.fedoraproject.org/rpms/ffmpeg/c/b3cfba90d45ccf7fdd58a4e0fa79e6527890b58d Dependents should take care to make sure that is accounted for.
Then please communicate that to the rpmfusion maintainers since they did not get the memo: https://pkgs.rpmfusion.org/cgit/free/ffmpeg.git/commit/?h=f39&id=635db1887428d9454bec1607cb35cc31959307dd otherwise chromium will fail to start for rpmfusion users once it starts linking against that symbol
(In reply to Bruno Pitrus from comment #14) > Then please communicate that to the rpmfusion maintainers since they did not > get the memo: > https://pkgs.rpmfusion.org/cgit/free/ffmpeg.git/commit/ > ?h=f39&id=635db1887428d9454bec1607cb35cc31959307dd > > otherwise chromium will fail to start for rpmfusion users once it starts > linking against that symbol I already told them this morning. It will not fail if people only install libavcodec-freeworld on top of ffmpeg-free, though. And we already recommend installing libavcodec-freeworld instead in that scenario.
Would adding the following: Conflicts: ffmpeg-libs%{_isa} Requires: libavformat-free%{_isa} >= 6.0.1 Recommends: libavcodec-freeworld%{_isa} to any downstream chromium packages guard against this scenario?
(In reply to Bruno Pitrus from comment #16) > Would adding the following: > Conflicts: ffmpeg-libs%{_isa} > Requires: libavformat-free%{_isa} >= 6.0.1 > Recommends: libavcodec-freeworld%{_isa} > > to any downstream chromium packages guard against this scenario? Yes, that should be fine.
Note that we cannot have that Recommends in Fedora proper packages (we're not allowed to reference non-Fedora packages to trigger installation), but COPR and OBS packages can.
(In reply to Neal Gompa from comment #13) > I am reintroducing the first_dts patch with ffmpeg-free-6.0.1. > > https://src.fedoraproject.org/rpms/ffmpeg/c/ > b3cfba90d45ccf7fdd58a4e0fa79e6527890b58d > Thanks for adding this patch back, Neal! Do you plan to add it for epel9 and fedora 37? Thanks
Bruno & Neal, Bringing up my proposal from https://bugzilla.redhat.com/show_bug.cgi?id=2249271#c9 as it seems relevant to Bruno's comment #16 This would achieve what you want without referring to libavcodec-freeworld at all in the spec sheet. Needs minor changes from rpmfusions side as well but should work. Tested and working on my side on Nobara
FEDORA-2023-108f6c4ef5 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-108f6c4ef5
FEDORA-2023-abef58ab49 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-abef58ab49
(In reply to Than Ngo from comment #19) > (In reply to Neal Gompa from comment #13) > > I am reintroducing the first_dts patch with ffmpeg-free-6.0.1. > > > > https://src.fedoraproject.org/rpms/ffmpeg/c/ > > b3cfba90d45ccf7fdd58a4e0fa79e6527890b58d > > > > Thanks for adding this patch back, Neal! Do you plan to add it for epel9 and > fedora 37? > > Thanks Yes. I intend to do it as part of doing the update to 5.1.4 for those branches.
ffmpeg-5.1.4 for f37 and epel9 is now proposed: * f37: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa089964c8 * epel9: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8024c335d1
FEDORA-2023-abef58ab49 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-abef58ab49` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-abef58ab49 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-108f6c4ef5 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-108f6c4ef5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-108f6c4ef5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
> ffmpeg-5.1.4 for f37 and epel9 is now proposed: > > * f37: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa089964c8 > * epel9: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8024c335d1 could someone please test and grant karma so it can be pushed to stable quickly? I would like to have this in chromium for fedora 37 and epel9! Thanks!
(In reply to Than Ngo from comment #27) > could someone please test and grant karma Using `chromium-119.0.6045.123-2.fc39.x86_64` which is supposed to fix this very ticket according to https://koji.fedoraproject.org/koji/buildinfo?buildID=2319736 , Chromium does not start on Fedora 39: [acko@fedora ~]$ chromium-browser /usr/bin/chromium-browser: symbol lookup error: /usr/bin/chromium-browser: undefined symbol: av_stream_get_first_dts, version LIBAVFORMAT_60 No such problem after downgrading to `chromium-119.0.6045.123-1.fc39.x86_64`; Chromium starts correctly. In case it's relevant, `ffmpeg-6.0-16.fc39.x86_64` is installed in both cases.
@a9016009 We are going to issue an urgent update to fix this issue on the rpmfusion side. But publishing such ABI breaking update fast is terrible!
FEDORA-2023-9425bb0115 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-9425bb0115` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9425bb0115 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-5b46676afa has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-5b46676afa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5b46676afa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-9425bb0115 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
This comment was flagged a spam, view the edit history to see the original text if required.
Hi non-guys, please file separate tickets for separate issues. Thanks.
FEDORA-2023-5b46676afa has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Andre Klapper from comment #36) > Hi non-guys, please file separate tickets for separate issues. Thanks. There was a separate ticket for the described teams issue: https://bugzilla.redhat.com/show_bug.cgi?id=2224141 and it was closed as a duplicate of this ticket. Should it be tracked in this ticket? Or re-open the "duplicate", or open a new ticket?
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days