Bug 224089 – [CMake][GStremer] Fails to build if OpenH264 is not present

• Component: WPE WebKit
• Status: RESOLVED FIXED

[Carlos Alberto Lopez Perez]

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

[Carlos Alberto Lopez Perez]

Created attachment 424970 [details]
Patch

[EWS]

Committed r275409: <https://commits.webkit.org/r275409>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 424970 [details].

[Michael Catanzaro]

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?

[Carlos Alberto Lopez Perez]

(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..