feat: Use pluginlib to load streamer plugins at runtime, general refactor

[bjsowa]

This is PR includes quite a large refactor and multiple improvements.

Improvements

• The largest improvement is using pluginlib to dynamically load streamers at runtime in a similar fashion as image_transport is loading it's subscriber and publisher plugins. This allows the user to extend the functionality without modifying the package, by writing plugins implementing StreamerFactoryInterface or SnapshotStreamerFactoryInterface.

• Significantly improved the stream list page. The streamer factories provide a method for getting a list of supported topics. The node is utilizing this method to show supported streamers for a given topic. Here's how it looked before:

  

  And here's after:

  

  Notice that ros_compressed is shown even for topics that don't have raw topics. (Fixes Compressed image topic not accessible #94)

• /snapshot request now support type parameter. This makes the snapshots not limited to jpeg. The user can specify png, ros_compressed or any format provided by a plugin implementing SnapshotStreamerFactoryInterface. (Fixes Snapshots only in JPEG ? #109)

Refactor

• Split the library into web_video_server and web_video_server_streamers. The idea behind it is to not have to link against OpenCV and ffmpeg when developing custom streamer plugins.
• Changed all method names to snake_case. There was a mix of snake_case and camelCase. I decided on sticking to snake_case as it's the naming convention used in core ROS packages.
• Changed some of the class names:
  • ImageStreamer -> StreamerInterface - although this is the primary function of web_video_server, we don't have to limit ourselves to streaming images.
  • ImageStreamerType -> StreamerFactoryInterface - I felt like Type was a bit misleading as this class is actually a factory for creating streamers.
  • ImageTransportImageStreamer -> ImageTransportStreamerBase, LibavStreamer -> LibavStreamerBase - to better reflect that these are common base classes used by plugins.
• Reorganized file structure to separate the core library and streamers.
• Modified include directives to include only what's used.

[sea-bass]

I really am not a fan of pluginlib, but I can definitely see the value or not loading every possible streamer type right away.

Code looks great, including all the cleanup on the wah. However, I think this needs some documentation on how to configure which plugins you want to load and how to launch a node properly. Can you add this in a README?

[bjsowa]

I really am not a fan of pluginlib, but I can definitely see the value or not loading every possible streamer type right away.

Well.. it still loads every streamer factory it can find. The pluginlib just allows declaring more streamers outside the package. image_transport declares a parameter for plugin whitelist but I don't see a sense of implementing it here as they don't pollute topics and overhead of loading them is negligible.

Now I'm curious why you dislike pluginlib and what alternative would you recommend instead.

Code looks great, including all the cleanup on the wah. However, I think this needs some documentation on how to configure which plugins you want to load and how to launch a node properly. Can you add this in a README?

I could add a section on how to create a package which adds another streamer type.

[sea-bass]

Now I'm curious why you dislike pluginlib and what alternative would you recommend instead.

I think pluginlib has a lot of weird behavior, and often exhibits memory leaks / failure to clean up on shutdown.

Plus, I'm generally of the belief that runtime configurability without compilation isn't worth forcing one to use a single abstract class and dealing with pluginlib idiosyncrasies. I prefer for people to have a flexible API and just recompile if needed.

No alternatives recommended --- I think this is just personal preference, but there is no real issue.

I could add a section on how to create a package which adds another streamer type.

Understood. I did think there was a path similar to image_transport as you described, where the node had a parameter listing out the plugins to load. If that's not the case, all good!

That would be great, though if you prefer to do that in a follow-on I can approve this now.

[bjsowa]

I'll add the documentation first to confirm whether this actually works

[bjsowa]

@sea-bass Finally managed to finish this, fixing some bugs on the way and testing it in practice.

[bjsowa]

@EzraBrooks Since you've been quite active in RWT lately, could you spare some time to look at this? 😄

[EzraBrooks]

I'll admit I have the same knee-jerk reaction as @sea-bass about distrusting pluginlib, but I understand not wanting to implement the dynamic loading yourself.

[EzraBrooks]

Generally seems fine. I certainly like the idea of formats being more pluggable.

[EzraBrooks]

I find it odd that something called "interface" has any non-virtual members, but it's not a huge deal.

[EzraBrooks]

I don't like the idea of changing the casing style of members without codifying a standard for this in the codebase. If we're going to break API anyway, I think we should go all-in on adopting a new clang-format/clang-tidy convention.