Motion Plugin Config File Discussion - Plugin Option

Refactored from MotionPluginConfigFileDiscussion

The Loading of Plugins

How do we load the plugins? Here we need to not only think user friendliness but also the code implementation. We need a syntax that is good for both user and code. Let me put some ideas and again I encourage more ideas so we can evaluate the pros and cons.

Plugins are loaded in common/global section and usage is defined in the camera section

In the common section there will be commands that loads the plugins. The load instruction contains the filename of the plugin. The idea is that first the Motion core parses the config file for the plugin option only and loads the plugins that register the options that introduce. Then the config file is parsed and and all options that are known (sum of core and plugin options) are loaded. Rest are ignored.

Some examples of possible syntax.

plugin v4l.so Relative path but relative to what?

plugin /usr/local/motion/plugin/v4l.so absolute path. What should be the default location used in rpms and debs?

plugin ffmpeg /usr/local/motion/plugin/motion_ffmpeg.so absolute path. Maybe we should use this syntax to name the plugin and not let the name depend on the filename.

plugin netcam /usr/local/motion/plugin/netcam.so

and then the camera section

[camera 1]
input_plugin v4l
movie_plugin ffmpeg

v4l_input_device /dev/video0
ffmpeg_video_codec mpeg4
.....

[camera 2]
input_plugin netcam
movie_plugin ffmpeg

netcam_url http:/192.168.1.45/video.cgi
ffmpeg_video_codec mpeg4ms
.....

Plugin and usage is loaded in the camera sections

Instead of having a seperate load statement in the common section we have a combined load and usage option in each camera section. This may in itself be simpler but I see some disadvantages as well.

• The code will now have to parse the camera sections as well for plugin options but still have to deal with them in a global context of plugin unique options are in the common scope - and that should be allowed.
• The user may find it less logical that plugins are loaded after the global common plugin options.
• The pathname to the same plugin can be different for each camera and I do not think it is a good idea to allow loading two different versions of the same plugin using the same options. I think it can create strange bugs. I would prefer that a loaded V4L option is the same for all camera.

Here is some example config.

[camera 1]
input_plugin v4l  /usr/local/motion/plugin/v4l.so
movie_plugin ffmpeg /usr/local/motion/plugin/motion_ffmpeg.so

v4l_input_device /dev/video0
ffmpeg_video_codec mpeg4
.....

[camera 2]
input_plugin netcam /usr/local/motion/plugin/netcam.so
movie_plugin ffmpeg /usr/local/motion/plugin/motion_ffmpeg.so

netcam_url http:/192.168.1.45/video.cgi
ffmpeg_video_codec mpeg4ms
.....

Sub conclusion on loading plugins

I think the first options is more coding friendly and more logical. The 2nd is more simple (only one option to load and use module).

I like number 1 most because though more complicated it is easier to code, and more logical. It also allows the use of input_plugin v4l once in the global section and if you then do not define it in the camera sections it becomes the default for then all. That makes configuration very easy for a typical system with a 4 input capture card - all v4l.

But then we have not considered proposal 3 and 4 which are not proposed yet. There are for sure more ways of doing it

-- KennethLavrsen - 08 Oct 2005