search

RobotWebTools / webrtc_ros

Streaming of ROS Image Topics using WebRTC
Other
131 stars 52 forks source link

Noetic Port #66

Open MoffKalast opened 2 years ago

MoffKalast commented 2 years ago

So hey, just wondering what's the current blocker for Noetic. Does anyone know how to compile the webrtc package properly (especially on armv7), or even better: where to find a "bootleg" already built version of it?

I see @kubja's supposed 20.04 compatibility PR https://github.com/RobotWebTools/webrtc_ros/pull/53 for the webrtc_ros driver has been merged a while ago, but nothing in that discussion is directly useful in actually getting it to work from my uninvolved perspective.

Regarding tips on how to build the thing, it would appear that ros-noetic-webrtc hasn't been released yet, same goes for the async_web_server. Is any of this still being maintained?

image

roehling commented 2 years ago

As it turns out, WebRTC remains a major pain to build. I have had very little time to look at this in more detail. PRs to fix this are very welcome and I will gladly re-release the WebRTC package to Noetic. The original async_web_server_cpp package is pretty much dead, which is why I have forked and released it myself.

MoffKalast commented 2 years ago

Okay, well I can probably get someone from my team to look at it but from what I understand webrtc_ros is actually already up to speed and what remains is a build farm issue for creating debs of the webrtc package for all platforms?

roehling commented 2 years ago

There are two packages: webrtc_ros is the ROS-specific implementation and depends on webrtc, which is basically the upstream Chromium WebRTC project. The webrtc_ros package is fine and has been fine since basically forever (save for a few API migrations, which turned out to be quite manageable).

I don't remember the latest issue that broke webrtc; it is a constant fight to keep the build afloat, because Chromium uses a custom "hermetic" build system which downloads (almost) everything and builds it from source (the final source tree has 6 to 8 gigabytes). I guess it is a viable strategy if you need to support a vast array of very different platforms, but it is definitely overkill if you are merely aiming for two, at most three, Ubuntu releases.

That alone would not be an issue (it just inflates the build time), but the custom build system depends on a depot_tools repository with a "live-at-HEAD" philosophy, which is a constant source of breakage; the depot_tools try very hard to update themselves automatically, introducing new features or deprecating old ones, which makes the build behave differently (and fail). Then there are third-party modules which move to different repositories or are removed from hosting altogether because the latest WebRTC snapshot no longer uses them. It's a nightmare to maintain. I did not test it, but I would not be surprised at all if it turns out that the Melodic packages no longer build either. The whole system is simply incapable of recreating a particular build environment consistently.