cefsrc and no GPU

[PrzemekGajos]

Hi All,

I'm trying to use cefsrc without drawing to a screen and without a GPU in my hardware. Does anyone know if GPU is a requirement for cefsrc or can it be run in a headless mode?

For an example, (note that I'm using a virtual environment with Xvfb), and a simple test pipeline produces: Xvfb :99 & export DISPLAY=:99

GST_PLUGIN_PATH=Release:$GST_PLUGIN_PATH gst-launch-1.0 cefsrc num-buffers=1 url=file:///home/root/urls/text.html ! video/x-raw,format=BGRA,width=1920,height=1080,framerate=60/1 ! filesink location=/home/root/buffer.raw Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock [1223/133936.433163:FATAL:gpu_data_manager_impl_private.cc(407)] GPU process isn't usable. Goodbye. Trace/breakpoint trap

Thanks, Przemek

[MathieuDuponchelle]

@PrzemekGajos I don't see why this would happen no, if you don't set the "gpu" property at least we pass "disable-gpu" and "disable-gpu-compositing" to CEF initialization.

Googling for that error, I find https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1877173 , which in turn links to other reports with several suggested workarounds, can you test those and report your findings?

[PrzemekGajos]

@MathieuDuponchelle I'm testing those workarounds and I'll inform on the outcome.

Some of them suggest using '--no-sandbox'. Is there a way to pass command-line arguments to cefsrc at run time or would it be embedding them in the source code, e.g. where 'disable-gpu' is set?

[MathieuDuponchelle]

@PrzemekGajos hardcode them and recompile, then we can expose properties if needed :)

[MathieuDuponchelle]

@PrzemekGajos I'm going to close this for lack of feedback, please reopen if you have more info ofc :)

[ghostnumber7]

Just to comment on this in case it might help. I noticed that this error happens when something is not properly linked when compiling or moving things around afterwards (as if it was a default error triggered by something completely unrelated (in my case I had issues after adding -DCMAKE_INSTALL_PREFIX=/usr when building), as is mentioned here). As far as i can tell, no-sandbox is configured already by default here so should not be needed as flag.

[reinismu]

Ye I have noticed as well. I didn't investigate, but if I move Release output to another folder it complains that GPU is not usable. Spent some time bashing my head. Now I just leave it where it is and haven't investigated further

[ghostnumber7]

I think I've found the cause for this. The subprocess bin path is configured with the absolute path when building here. Then that's called at runtime to spawn the subprocess or alike here, so no matter where the other files are it will spawn that bin from build path only. I'm trying to modify that behavior, will ping if I manage to do something with it, as it can't be relative

[ghostnumber7]

This is not really an elegant solution but it's working. Basically modified CMakeLists.txt to accept an optional "install path" that will be used instead of the build directory as follows:

--- target_compile_definitions("gstcef" PUBLIC "-DCEF_SUBPROCESS_PATH=\"$<TARGET_FILE:gstcefsubprocess>\"")
+++ if (DEFINED CEF_SUBPROCESS_BASE_PATH)
+++   set(CEF_SUBPROCESS_PATH "${CEF_SUBPROCESS_BASE_PATH}/gstcefsubprocess")
+++ else()
+++   set(CEF_SUBPROCESS_PATH "$<TARGET_FILE:gstcefsubprocess>")
+++ endif()
+++ target_compile_definitions("gstcef" PUBLIC "-DCEF_SUBPROCESS_PATH=\"${CEF_SUBPROCESS_PATH}\"")

Then I can build with that option and move files there

cmake \
      -DCEF_SUBPROCESS_BASE_PATH=/usr/lib/x86_64-linux-gnu/gstreamer-1.0/ \
      -DCMAKE_BUILD_TYPE=Release \
      -G"Unix Makefiles" .. && make && mv ./Release/* /usr/lib/x86_64-linux-gnu/gstreamer-1.0/

I guess a better approach would be to create a proper make install config with CMAKE_INSTALL_PREFIX or alike to make it standard.

[reinismu]

@ghostnumber7 put in an PR we can start a discussion and merge it. I would note this issue in README as well