224089 2021-04-01 17:50:58 -0700 [CMake][GStremer] Fails to build if OpenH264 is not present 2021-04-02 10:11:43 -0700 1 1 1 Unclassified WebKit WPE WebKit WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=202538 P2 Normal --- 1 clopez clopez annulen bugs-noreply calvaris eric.carlson ews-watchlist gyuyoung.kim mcatanzaro pnormand ryuan.choi sergio youennf oldest_to_newest 1746347 0 clopez 2021-04-01 17:50:58 -0700 In r275275 optional support for using OpenH264 was added. However, this seems to be failing to build when OpenH264 is not present because of CMake trying to link with a library that is not defined See: -- Enabled features: -- ENABLE_ACCESSIBILITY .......................... ON -- ENABLE_BUBBLEWRAP_SANDBOX OFF -- ENABLE_ENCRYPTED_MEDIA ........................ ON -- ENABLE_GTKDOC OFF -- ENABLE_MEDIA_SOURCE ........................... ON -- ENABLE_MINIBROWSER ON -- ENABLE_VIDEO .................................. ON -- ENABLE_WEBDRIVER ON -- ENABLE_WEB_AUDIO .............................. ON -- ENABLE_WEB_CRYPTO ON -- ENABLE_WPE_QT_API ............................. OFF -- ENABLE_XSLT ON -- USE_LCMS ...................................... ON -- USE_OPENJPEG ON -- USE_SOUP2 ..................................... ON -- USE_SYSTEMD ON -- USE_WOFF2 ..................................... ON CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: Openh264_LIBRARY (ADVANCED) linked by target "webrtc" in directory /home/buildbot/wpewebkit/nightly/wpe-linux-64-packaging-nigthly-ubuntu1804/build/Source/ThirdParty/libwebrtc -- Configuring incomplete, errors occurred! See also "/home/buildbot/wpewebkit/nightly/wpe-linux-64-packaging-nigthly-ubuntu1804/build/WebKitBuild/Release/CMakeFiles/CMakeOutput.log". See also "/home/buildbot/wpewebkit/nightly/wpe-linux-64-packaging-nigthly-ubuntu1804/build/WebKitBuild/Release/CMakeFiles/CMakeError.log". FAILED: build.ninja ^^ https://build.webkit.org/#/builders/52/builds/56/steps/8/logs/stdio 1746350 1 424970 clopez 2021-04-01 17:58:52 -0700 Created attachment 424970 Patch 1746413 2 ews-feeder 2021-04-02 01:20:01 -0700 Committed r275409: <https://commits.webkit.org/r275409> All reviewed patches have been landed. Closing bug and clearing flags on attachment 424970. 1746489 3 mcatanzaro 2021-04-02 07:32:42 -0700 Will this still be needed in the gst-webrtc implementation? I wonder what the goal is. It looks like it is not compatible with noopenh264, right? If it was, and if it would still be needed with gst-webrtc, then I could look into packaging noopenh264 for Fedora, to allow this to build, but that requires runtime checks in the application to make sure you're running against real OpenH264 and not noopenh264. Why is it preferred over x264enc? 1746555 4 clopez 2021-04-02 10:11:43 -0700 (In reply to Michael Catanzaro from comment #3) > Will this still be needed in the gst-webrtc implementation? > > I wonder what the goal is. It looks like it is not compatible with > noopenh264, right? If it was, and if it would still be needed with > gst-webrtc, then I could look into packaging noopenh264 for Fedora, to allow > this to build, but that requires runtime checks in the application to make > sure you're running against real OpenH264 and not noopenh264. > > Why is it preferred over x264enc? This is for libwebrtc, which is not shipped on the tarballs, so I guess is not something a distributor should worry for the moment. I don't know why is preferred. Maybe ask on bug 202538 for that.. 424970 2021-04-01 17:58:52 -0700 2021-04-02 01:20:03 -0700 Patch bug-224089-20210402025850.patch text/plain 1374 clopez U3VidmVyc2lvbiBSZXZpc2lvbjogMjc1Mzk2CmRpZmYgLS1naXQgYS9Tb3VyY2UvVGhpcmRQYXJ0 eS9saWJ3ZWJydGMvQ2hhbmdlTG9nIGIvU291cmNlL1RoaXJkUGFydHkvbGlid2VicnRjL0NoYW5n ZUxvZwppbmRleCBmZDU1Y2ExZjIzYjhjNTUxYmQ4YjNjYWZkOGY1ODJjZTU1ZWY5ZTFjLi5kYzNk ZDJlMmJlM2I3Mzc0MGY3YTAwOGNmYjQxMGZlOTAzNGJiYmJiIDEwMDY0NAotLS0gYS9Tb3VyY2Uv VGhpcmRQYXJ0eS9saWJ3ZWJydGMvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9UaGlyZFBhcnR5L2xp YndlYnJ0Yy9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxMiBAQAorMjAyMS0wNC0wMSAgQ2FybG9zIEFs YmVydG8gTG9wZXogUGVyZXogIDxjbG9wZXpAaWdhbGlhLmNvbT4KKworICAgICAgICBbQ01ha2Vd W0dTdHJlbWVyXSBGYWlscyB0byBidWlsZCBpZiBPcGVuSDI2NCBpcyBub3QgcHJlc2VudAorICAg ICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjI0MDg5CisKKyAg ICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBDTWFrZUxpc3Rz LnR4dDogT25seSB0cnkgdG8gbGluayB3aXRoIE9wZW5IMjY0IHdoZW4gaXQgaXMgZm91bmQuCisK IDIwMjEtMDMtMzEgIFlvdWVubiBGYWJsZXQgIDx5b3Vlbm5AYXBwbGUuY29tPgogCiAgICAgICAg IEluIGNhc2UgV2ViUlRDIFZUQiBkZWNvZGVyIHJldHVybnMgYSBudWxsIGZyYW1lLCBtYXJrIHRo ZSBkZWNvZGVyIGFzIGZhaWxpbmcKZGlmZiAtLWdpdCBhL1NvdXJjZS9UaGlyZFBhcnR5L2xpYndl YnJ0Yy9DTWFrZUxpc3RzLnR4dCBiL1NvdXJjZS9UaGlyZFBhcnR5L2xpYndlYnJ0Yy9DTWFrZUxp c3RzLnR4dAppbmRleCBjMDYzNWI0NjEzMDM4MjhjYzMyZGYwMGMzN2Q3YTAyZjk3YTQ3ODAyLi44 MGY4OTQyODA4ZjI3ZTcwNTgzNGFhZDQ1OTUwMDE3N2Y5ZDBlYzFlIDEwMDY0NAotLS0gYS9Tb3Vy Y2UvVGhpcmRQYXJ0eS9saWJ3ZWJydGMvQ01ha2VMaXN0cy50eHQKKysrIGIvU291cmNlL1RoaXJk UGFydHkvbGlid2VicnRjL0NNYWtlTGlzdHMudHh0CkBAIC0xNTMwLDcgKzE1MzAsOSBAQCB0YXJn ZXRfbGlua19saWJyYXJpZXMod2VicnRjICR7TElCRVZFTlRfTElCUkFSWX0pCiAKIHRhcmdldF9s aW5rX2xpYnJhcmllcyh3ZWJydGMgJHtMSUJPUFVTX0xJQlJBUll9KQogCi10YXJnZXRfbGlua19s aWJyYXJpZXMod2VicnRjICR7T3BlbmgyNjRfTElCUkFSWX0pCitpZiAoT3BlbmgyNjRfRk9VTkQp CisgICAgdGFyZ2V0X2xpbmtfbGlicmFyaWVzKHdlYnJ0YyAke09wZW5oMjY0X0xJQlJBUll9KQor ZW5kaWYgKCkKIAogIyBsaWJzcnRwIHBhY2thZ2UgY29tcGlsYXRpb24KIHNldChsaWJzcnRwX1NP VVJDRVMK