Skip to content
This repository has been archived by the owner on Jul 12, 2023. It is now read-only.

Compile arm64 on Ubuntu-18.04 64bit from Source Kurento/gstreamer & Kurento/gst-plugins-base gstreamer-1.5 vs gstreamer-1.8 #450

Closed
4 tasks
toqana opened this issue Mar 18, 2020 · 5 comments
Assignees
Labels
not-a-bug Anything that doesn't really constitute a bug report

Comments

@toqana
Copy link

toqana commented Mar 18, 2020

Prerequisites

  • [x ] I have read the SUPPORT document

  • [ x] I have checked the Troubleshooting Guide

  • [ x] I have tested with the latest version of Kurento

Issue description

When compiling from the latest source from https://github.com/Kurento/gstreamer, it appears as if gstreamer-1.5 is being installed instead of gstreamer-1.8:

git clone https://github.com/Kurento/gstreamer.git
cd gstreamer
grep -rin 'gstreamer-1.5' . (see several output lines below)

./gstreamer.doap:167:
./plugins/tracers/Makefile:309:GETTEXT_PACKAGE = gstreamer-1.5
./plugins/Makefile:274:GETTEXT_PACKAGE = gstreamer-1.5

When compiling from the latest source from https://github.com/Kurento/gst-plugins-base, when "./autogen.sh" is run the following error message appears:

checking for GST... no
configure: No package 'gstreamer-1.5' found
configure: error: no gstreamer-1.5 >= 1.8.0 (GStreamer) found
configure failed

I have been following an English translation of the post dated 2020-02-14, https://bbs.huaweicloud.com/blogs/147677, to compile KMS on a different arm64 machine, the RPi4 running Ubuntu-18.04 64bit.

Until step "2.3.11 Compile and install gst-plugins-base" there have been no issues.

Questions:

  1. What version of gstreamer is required to compile from source?

  2. What version of kms should be specified on the "git checkout kms6.6.0" command when compiling from source? The post dated 2020-02-14, https://bbs.huaweicloud.com/blogs/147677 uses "git checkout kms6.6.0", even though kms6.6.0 is dated.

  3. If appropriate, we can modify https://github.com/Kurento/gstreamer or https://github.com/Kurento/gst-plugins-base if we know what version of gstreamer is required.

Context

This has stopped the effort to compile KMS from source for the arm64 RPi4 running Ubuntu-18.04 64bit which is intended to provide a low cost solution for private video conferenceing using KMS and OpenVidu.

Since it appears that arm64 is not supported for .deb or docker for KMS and OpenVidu, compiling from source appears to be the only method available to use KMS and OpenVidu on the arm64 RPi4 running Ubuntu-18.04 64bit.

How to reproduce?

Expected & current behavior

(Optional) Possible solution

Environment info

INFO: Kurento Media Server

  • Kurento version:
  • Server OS:
  • Installation method:
    • apt-get
    • Docker
    • AWS
    • Built from sources

INFO: Application Server

  • Language:
  • Kurento Client version:

INFO: End-user clients

  • Device(s):
  • OS(es):
  • Browser(s):

Version details

lsb_release -a

kurento-media-server -v

dpkg -l | grep -Pi 'kurento|kms-|gst.*1.5|nice'
@j1elo
Copy link
Member

j1elo commented Mar 26, 2020

Do not confuse "gstreamer-1.5" as a package name, with "1.8" as a version number. I guess our GStreamer forks contain "1.5" in their names because originally they were forked from GStreamer 1.5.x, but with time they were updated and currently they are based on the 1.8.x version of Gstreamer.

Similarly, you'll notice that on Ubuntu the packages are called "gstreamer-1.0", even though the actual version is 1.14 (for Ubuntu 18.04).

In order to build each of the Kurento forks, you need previously build all its dependencies. Here you have a nice graph where the dependency tree can be checked:
Code repositories

You should be able to use dpkg-buildpackage -us -uc to build .deb packages out of all forks and projects belonging to Kurento, following the dependency tree. Each new project requires that previous ones are installed in the system, so you need to work iteratively from the very first one to the last one. Our CI does that, and all builds are done by following the repository order suggested in the previous link.

Note that for the upcoming Kurento 7 we are working to drop our fork of GStreamer, and instead use the version that is provided by the operating system:
PSA: Kurento 7.0 moving to GStreamer 1.14 in Bionic

Also note that it was a long time ago that we dropped the old package names including the "6" in the name. For example, it was "kms-core-6.0" and "kurento-media-server-6.0", but since a couple years ago that became "kms-core" and "kurento-media-server". If you are following instructions that work with version 6.6, that's already "prehistoric" :-)

Last note, we've made it easier to build KMS from sources (on the supported platforms) by writing an all-in-one build script (kms-build-run), so maybe is still is useful for you even in other plaftorms: Build from sources.

@j1elo
Copy link
Member

j1elo commented Mar 26, 2020

Notice how the build dependencies for every project are codified in the file debian/control, under Build-Depends.

@toqana
Copy link
Author

toqana commented Mar 28, 2020

Hello Juan,

Thank you for your quick response. As you suggested, .deb files were built.

However, I was unable to build gst-plugins-bad (also openh264-gst-plugin which seems to build gst-plugins-bad as shown below).

Therefore, kms-core could not be built.

Can you explain how to build gst-plugins-bad? The file libgstopenh264.so seems to be missing.

The dependencies shown in https://doc-kurento.readthedocs.io/en/latest/dev/dev_guide.html#code-repositories were followed to build .deb files in this order:

jsoncpp			no errors

libsrtp			no errors

openh264		no erros

kms-cmake-utils		no errors

gstreamer		no errors

gst-plugins-base	no errors

gst-libav		no errors

libusrsctp		no errors

openwebrtc-gst-plugins	no errors

gst-plugins-good	no errors

gst-plugins-bad		dh_install: Cannot find (any matches for) "debian/tmp/usr/lib/*/gstreamer-1.5/libgstopenh264.so" (tried in ., debian/tmp)

openh264-gst-plugin	dh_install: Cannot find (any matches for) "gst-plugins-bad1.0-*/debian/tmp/usr/lib/*/gstreamer-1.0/libgstopenh264.so" (tried in ., debian/tmp)

--- openh264-gst-plugin information not understood start ---

https://github.com/Kurento/openh264-gst-plugin/blob/master/configure

\# Launch the build
\# Package construction will fail, but only after having built our file
debuild -b -uc -us --target=install-arch || true

https://github.com/Kurento/openh264-gst-plugin/tree/master/debian

Build method
============

In order to build the OpenH264 GStreamer plugin, this project contains a './configure' file that will download and build 'gst-plugins-bad' while ensuring that OpenH264 is already installed in the system.

--- openh264-gst-plugin information not understood end ---

gst-plugins-ugly	no errors

kms-jsonrpc		no errors

kms-module-creator	no errors

kms-core		"dpkg-buildpackage -b -rfakeroot -us -uc" failed due to no gst-plugins-bad

kms-core		"dpkg-buildpackage -b -rfakeroot -us -uc --no-check-builddeps" failed

--- kms-core "dpkg-buildpackage -b -rfakeroot -us -uc --no-check-builddeps" output start ---

...

Running tests...

/usr/bin/ctest --force-new-ctest-process -j4
Test project /home/ubuntu/kms/kms-core/obj-aarch64-linux-gnu
      Start  1: test_hubport
      Start  2: test_filterelement
      Start  3: test_agnosticbin
      Start  4: test_agnosticbin_negotiation
 1/24 Test  #1: test_hubport .....................   Passed    0.51 sec
 2/24 Test  #2: test_filterelement ...............   Passed    0.60 sec
      Start  5: test_agnosticbin3
      Start  6: test_audiomixerbin
 3/24 Test  #6: test_audiomixerbin ...............***Failed    0.10 sec
Running suite(s): audiomixerbin


Unexpected critical/warning: gst_bin_add: assertion 'GST_IS_ELEMENT (element)' failed
0%: Checks: 1, Failures: 1, Errors: 0
gstcheck.c:79:F:element:check_audio_disconnection:0: Unexpected critical/warning: gst_bin_add: assertion 'GST_IS_ELEMENT (element)' failed

      Start  7: test_bufferinjector
 4/24 Test  #4: test_agnosticbin_negotiation .....   Passed    1.90 sec
      Start  8: test_pad_connections
 5/24 Test  #5: test_agnosticbin3 ................   Passed    1.41 sec
      Start  9: test_passthrough
 6/24 Test  #8: test_pad_connections .............   Passed    2.21 sec
      Start 10: test_sdp_agent
 7/24 Test  #7: test_bufferinjector ..............   Passed    3.42 sec
 8/24 Test #10: test_sdp_agent ...................   Passed    0.61 sec
      Start 11: test_metadata
      Start 12: test_lists
 9/24 Test #11: test_metadata ....................   Passed    0.31 sec
      Start 13: test_utils
10/24 Test #12: test_lists .......................   Passed    0.31 sec
11/24 Test #13: test_utils .......................   Passed    0.20 sec
      Start 14: test_refcounts
      Start 15: test_rembmanager
12/24 Test #14: test_refcounts ...................   Passed    0.31 sec
      Start 16: test_rtpsync
13/24 Test #15: test_rembmanager .................   Passed    0.31 sec
14/24 Test #16: test_rtpsync .....................   Passed    0.20 sec
      Start 17: test_module_manager
      Start 18: test_media_set
15/24 Test  #9: test_passthrough .................   Passed    3.76 sec
16/24 Test #17: test_module_manager ..............   Passed    0.21 sec
      Start 19: test_media_element
      Start 20: test_rtp_endpoint_cpp
17/24 Test #18: test_media_set ...................   Passed    0.21 sec
18/24 Test #20: test_rtp_endpoint_cpp ............   Passed    0.19 sec
19/24 Test #19: test_media_element ...............   Passed    0.19 sec
      Start 21: test_sdp_endpoint
      Start 22: test_media_object
      Start 23: test_complex_type
20/24 Test #22: test_media_object ................   Passed    0.21 sec
21/24 Test #21: test_sdp_endpoint ................   Passed    0.21 sec
      Start 24: test_uri_endpoint
22/24 Test #23: test_complex_type ................   Passed    0.21 sec
23/24 Test #24: test_uri_endpoint ................   Passed    0.12 sec
24/24 Test  #3: test_agnosticbin .................   Passed   42.87 sec

96% tests passed, 1 tests failed out of 24

Total Test time (real) =  42.88 sec

The following tests FAILED:
	  6 - test_audiomixerbin (Failed)
Errors while running CTest
Makefile:97: recipe for target 'test' failed
make[1]: *** [test] Error 8
make[1]: Leaving directory '/home/ubuntu/kms/kms-core/obj-aarch64-linux-gnu'
dh_auto_test: cd obj-aarch64-linux-gnu && make -j4 test ARGS\+=-j4 returned exit code 2
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

--- kms-core "dpkg-buildpackage -b -rfakeroot -us -uc --no-check-builddeps" output end ---

@j1elo j1elo self-assigned this Jun 18, 2020
@j1elo j1elo added the not-a-bug Anything that doesn't really constitute a bug report label Jun 18, 2020
@j1elo
Copy link
Member

j1elo commented Jun 18, 2020

gst-plugins-bad		dh_install: Cannot find (any matches for) "debian/tmp/usr/lib/*/gstreamer-1.5/libgstopenh264.so" (tried in ., debian/tmp)

openh264 needs to be already installed before gst-plugins-bad is built. When i gst-plugins-bad is preparing to build, it does some autodetection checks, and enables or disables some codecs depending on what it sees available in the system. So, if OpenH264 is not available, gst will not build the libgstopenh264 library.

So the order would be: 1) openh264, 2) gst-plugin-bad. Have a look at the repositories dependency graph: https://doc-kurento.readthedocs.io/en/latest/dev/dev_guide.html#code-repositories

On the other hand, openh264-gst-plugin is only needed if you are building the bionic-gstreamer branch, that runs on Ubuntu Bionic and doesn't use any of our GStreamer forks, instead it uses the gstreamer-1.0 that is provided by the system itself.

@j1elo
Copy link
Member

j1elo commented Jan 18, 2023

Old Kurento fork of GStreamer 1.8 (packages named "gstreamer1.5") are dropped for Kurento 7, and instead now it will just use the GStreamer that is available in the system (note only GStreamer 1.16 from Ubuntu 20.04 has been tested)

@j1elo j1elo closed this as completed Jan 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
not-a-bug Anything that doesn't really constitute a bug report
Projects
None yet
Development

No branches or pull requests

2 participants