OpenH264 library for non-x86_64-Linux environments about mediadevices

[at-wat]

@a1xon could you open a new issue with detailed informations of your configuration?
(e.g. including Go version, what kind of camera do you use, changes in sample code if something changed, etc)

[lherman-cs]

This has been my goal. The original thought was to bundle everything statically and reduce the number of dependencies that you need to install (basically I want people to be able to just get the library by go get and just build their code with it, no need apt-get install or anything like that). My aggressive goal is to actually write these codecs in pure Go, but obviously we don't have the time for that yet... ^^

From my research in the past, we can build the libraries statically for every OS and architecture, and link them conditionally in Go (which is somewhat what we currently have, we just need to extend more support to other OS and arch).

In fact, this approach has been done before in a project called, mysterium:

• Blog post specifically about this, https://medium.com/mysterium-network/golang-c-interoperability-caf0ba9f7bf3
• The source codes, https://github.com/mysteriumnetwork/go-openvpn/tree/master/openvpn3

Honestly, the main problem has been getting hardware with different OSes and arch to compile it statically. I saw some articles that you could use Docker to get the proper toolchain for cross-compilation. But, I'm not sure how we can do cross-OS compilations since Windows and Mac toolchain can't be used in Linux AFAIK.

Also, it seems that making a static build with cgo might become easier in the future with this proposal, golang/go#26492. I really wonder that if it's going to be possible to cross-compile with cgo in the future... It would be pretty awesome!

[at-wat]

I agree that bundling everything statically is useful.
However, static link is sometimes problematic due to their licenses (currently, linked libs excepting libgcc are all BSD-like, so it's OK) and binary size when building multiple executables. It would be better to be selectable via -tags or something.

[lherman-cs]

That makes sense. But, it seems like OpenH264 doesn't distribute their dynamic version to package managers... I'm having a hard time to find one for Ubuntu.

[at-wat]

Hmm, it seems that Cisco's AVC/H.264 Patent Portfolio is only applied to their precompiled binary.

http://www.openh264.org/faq.html
http://www.openh264.org/BINARY_LICENSE.txt

The binary form of this Software is distributed by Cisco under the AVC/H.264 Patent Portfolio License from MPEG LA, and is subject to the following requirements, which may or may not be applicable to your use of this software:

[lherman-cs]

Ah, that explains why we can't find the dynamic library.

[a1xon]

So using mediadevices will not be possible on an RPi? :\

[at-wat]

@a1xon You can use system wide installed openh264 library instead of using bundled one by specifying -tags dynamic.

[a1xon]

@a1xon You can use system wide installed openh264 library instead of using bundled one by specifying -tags dynamic.

Tried that with the simple example on the RPi 4 (2GB) and I'm getting Failed to map request buffers: cannot allocate memory for GetUserMedia(). I also rebuild openh264 and replaced the lib/libopenh264.x86_64-linux.a file.