I first perceived the problem when I tried to make remote meetings through MS Teams and video could not be neither streamed outbound nor inbound. After filing a bug on Chromium's issue tracker [https://issues.chromium.org/issues/41492618), we were able to track the problem to the fact that on Fedora Chromium is incapable of dynamically loading H264 libs (even though they are installed), and therefore it cannot stream H264 content. This first issue was closed as an MS Teams issue, so I created a new, more specific one (https://issues.chromium.org/issues/324534609), but this last one was closed as "won't fix -- intended behavior" with the final comment saying "We don't provide support for distro builds. They often use custom Chromium patches. You'll need to reach out to Fedora.". So, here we are, hoping this is the right place and the issue will finally be addressed. Reproducible: Always Steps to Reproduce: 1. Join a meeting with MS Teams 2. Try to stream video of any kind (camera, screencast etc.) 3. Actual Results: No video of any kind is streamed inbound or outbound. Expected Results: Video should be properly sent and received.
Reproducing here the comments made by Chromium devs on https://issues.chromium.org/issues/324534609: > Proprietary codecs are only supported with proprietary_codecs=true ffmpeg_branding=Chrome. If you're setting use_system_ffmpeg, we also can't be sure what is actually supported locally. > If you don't set any additional flags, then H.264 should not work. (these are compile-time flags) I downloaded chromium-121.0.6167.184-1.fc39.src.rpm and there are 58 patches in total, including chromium-107-proprietary-codecs.patch that removes the following lines from media/BUILD.gn : -if (proprietary_codecs && media_use_ffmpeg) { - assert( - ffmpeg_branding != "Chromium", - "proprietary codecs and ffmpeg_branding set to Chromium are incompatible") -} My question is: considering all the patches applied, should chromium support h264 content on a Fedora installation with openh264 installed? For the record, these are the h264 packages currently installed here: openh264-2.3.1-2.fc39.x86_64 mozilla-openh264-2.3.1-2.fc39.x86_64 gstreamer1-plugin-openh264-1.22.1-1.fc39.x86_64 Chrome supports h264, but it uses its own ffmpeg libs. Firefox also supports h264, and it uses Fedora's openh264 libs.
For the record, I am already using ffmpeg from RPMFusion: ❯ rpm -q --queryformat "%{NAME} %{VERSION}: %{VENDOR}\n" ffmpeg ffmpeg-libs ffmpeg 6.0.1: RPM Fusion ffmpeg-libs 6.0.1: RPM Fusion I also followed the instructions from RPMFusion Multimedia howto [https://rpmfusion.org/Howto/Multimedia]. Still, running this JS Fiddle (https://jsfiddle.net/fippo/rLhug0dp/) shows "undefined" on Chromium, while on Chrome it shows {"clockRate":90000,"mimeType":"video/H264","sdpFmtpLine":"level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f"}
I've also encountered that problem with Teams after Fedora upgrade to the version with chromium-freeworld not available anymore ("because the version in Fedora should be able to do the same" :) ). As Teams (especially v2) has poor support also for Firefox (not to mention a lack of a native app), it is currently problematic to use Teams on Fedora 39 without using Google Chrome, manual compilation of Chromium (with changes patches) or using third party binaries :-/. Maybe it would be possible to address that on the Fedora side?
I changed the issue's title because I realized we might have a different problem. With Chromium 123.0.6312.105-1, h264 codec seems to be supported; running the JSFiddle shows the same output as Chrome: {"clockRate":90000,"mimeType":"video/H264","sdpFmtpLine":"level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f"} Also, https://mozilla.github.io/webrtc-landing/pc_test_no_h264.html shows "YES H.264 is supported!". Still, I can't send nor receive video on MS Teams (Google Meet works just fine). Running chromium-browser on console shows this during a MS Teams call with video enabled: [41032:31:0412/152139.077691:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [40118:40145:0412/152155.639260:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [40118:40145:0412/152155.639391:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [40118:40145:0412/152155.639416:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [41032:31:0412/152208.078466:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.079403:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.080315:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.081284:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.082167:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.083090:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.083959:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.084839:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.085685:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.086533:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [41032:31:0412/152208.087527:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. [40118:40145:0412/152208.247626:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [40118:40145:0412/152208.247698:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [40118:40145:0412/152208.247726:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [40117:41160:0412/152210.225693:ERROR:vaapi_video_decoder.cc(1232)] failed Initialize()ing the frame pool [41032:31:0412/152248.003066:ERROR:stun_port.cc(101)] Binding request timed out from 192.168.0.x:54664 (enp3s0) [41032:31:0412/152248.003231:ERROR:stun_port.cc(101)] Binding request timed out from 192.168.68.x:52899 (wlp4s0) [41032:31:0412/152442.691530:ERROR:webrtc_video_engine.cc(1053)] No video codecs in common. The same attempt with Chrome results in: [41648:41654:0412/153030.398312:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [41648:41654:0412/153030.398400:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [41648:41654:0412/153030.398450:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [41648:41654:0412/153042.551801:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [41648:41654:0412/153042.551849:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [41648:41654:0412/153042.551885:ERROR:socket_manager.cc(141)] Failed to resolve address for world.relay.skype.com., errorcode: -105 [OpenH264] this = 0x0x3d0c19ccdf80, Warning:Actual input framerate 0.000000 is different from framerate in setting 30.000000, suggest to use other rate control modes [OpenH264] this = 0x0x3d0c19ccdf80, Warning:Actual input framerate 0.000000 is different from framerate in setting 30.000000, suggest to use other rate control modes So, there is clearly a codec problem, but I can't pinpoint what it is.
For the record: I filed yet another bug on Chromium issue tracker (https://issues.chromium.org/issues/341991523), but all evidences point to the problem being specific to Chromium's Fedora build (e.g. it is able to send/receive video on Debian).
(In reply to Andre Costa from comment #5) > For the record: I filed yet another bug on Chromium issue tracker > (https://issues.chromium.org/issues/341991523), but all evidences point to > the problem being specific to Chromium's Fedora build (e.g. it is able to > send/receive video on Debian). there's new scratch build with the proposed fix for this issue. Could you please download and test? Please give the feedback https://koji.fedoraproject.org/koji/taskinfo?taskID=118216347 Thanks
*** Bug 2252489 has been marked as a duplicate of this bug. ***
i want to mention that the above scratch build is only for f40
i @than thanks for working on this. I downloaded this specific build you suggested, and I could successfully send and receive video and audio on MS Teams \o/ (I tested with two different Teams accounts, one on the browser and another one on my mobile). I didn't test screensharing yet, but I would assume it will work considering video is being transmitted successfully. Just out of curiosity, what was the solution after all? Does the 'noopenh264' on the package name mean that chromium will now ship with its own libs, as (I assume) Chrome does?
The solution is simply that we link Chromium against noopenh264 library (the fake implementation of the OpenH264 library), regardless of the availability of the actual library. noopenh264 is installed by default in Fedora Workstation. Then during the first system update, it should get replaced by the real openh264 package from Cisco's repository.
FEDORA-2024-4e0ea1c22e (chromium-125.0.6422.141-1.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-4e0ea1c22e
FEDORA-2024-bb52629e6c (chromium-125.0.6422.141-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb52629e6c
FEDORA-2024-4e0ea1c22e 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-2024-4e0ea1c22e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-4e0ea1c22e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-bb52629e6c has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-bb52629e6c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb52629e6c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-bb52629e6c (chromium-125.0.6422.141-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-4e0ea1c22e (chromium-125.0.6422.141-1.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-a9e91ea153 (chromium-125.0.6422.141-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-a9e91ea153
FEDORA-2024-a9e91ea153 (chromium-125.0.6422.141-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.