Added Custom path conf field (#5406)

[Snafu]

Available as MTX_CUSTOM env var to RunOnInit, RunOnReady, RunOnNotReady, RunOnDemand, RunOnUndemand

[Snafu]

Hi, I added the field "Custom" in the path config because in my setup I am using ffmpeg in a runOnReady script to create multiple transcodings and want to pass it some extra information without polluting MTX_PATH or misusing another path config field.
I tested it and it works as expected.

Implements feature request #5406

[Snafu]

Hi @aler9 ,
MediaMTX is an excellent tool, but when running an external tool like ffmpeg for transcoding there really isn't a way to pass path specific settings to a script running ffmpeg. Maybe one could abuse one of the rpi config properties but that would be an ugly way to do so. The proposed change request with MTX_CUSTOM is very basic and would allow a multipurpose config property for all kinds of purposes. I'm also happy to provide a different solution based on any received feedback.
Would be nice if this change could be included.

BR

[aler9]

Hello @Snafu, the problem here is that we've always avoided merging patches that added generic properties to paths, because external properties are meant to be saved outside the server, in an external wrapper. The main reason for this is to avoid imposing a data model for additional properties which wouldn't satisfy everyone, for instance, in this case you assigned a single "custom" field to each path, and this field is a string, but i can think about several other data models, for instance there are people that asked to add custom key/value properties to each path, some of which are using integer keys, others string keys. Therefore: the feature is not universal and not directly bound to any server feature.

Using "custom" to personalize hooks has its usefulness, but you could also hardcode these values inside hooks, eventually duplicating path definitions in order to cover each case:

paths:
  path1:
    runOnReady: ffmpeg with hardcoded MTX_CUSTOM_1
  path2:
    runOnReady: ffmpeg with hardcoded MTX_CUSTOM_2
...

Therefore: we prefer to keep integrations outside the servers, in order to concentrate on streaming-specific issues, nonetheless it's perfectly possible to develop integrations, by placing them outside the server and interacting with the current server interfaces (configuration file / API).

Of course if you spot something that cannot be currently done, even in a really verbose way, report that and feel free to send a patch for that.

[Snafu]

Hi @aler9,
thanks for the reply! In my case I am using MediaMTX with no fixed paths and am exclusively creating paths on demand. The path configs are pretty much identical all the time, so I can configure a lot with the pathDefaults entry, which is extremely useful. However, since MediaMTX cannot transcode by itself, I need to run ffmpeg to do the transcoding, if required. This is no problem, but I would like to still use the pathDefaults as much as possible and only pass the really relevant information, such as which resolutions and what codecs to use to ffmpeg through the path config and not write a different scipt name or even a full ffmpeg command in the API call that creates the path. I don't want that code to be touched more than necessary.

Currently I've got a very nasty solution by having some information hidden in the path name that I am creating (think a suffix that is the hex representation of a bit mask), but that is a very ugly and hacky way to do so.
I agree that people will want to store information in all kinds of ways, such as hashmaps or arrays or any other possible way. That fact is exactly why I think a very basic generic misc / custom field would be a good solution to simply have MediaMTX play the messenger but not have to worry about what it is really used for. I would have the content of MTX_CUSTOM be the JSON encoded data I want to have available in my script, which I can access through the env var, someone else may put a base64 encoded image in there that should be used as an icon. MediaMTX shouldn't need to worry about that at all, but it would be nice if it were able to relay that information.

Of course I could store the data I need in some database and have a custom API which I use to query that database for transcoding information, but that is in my mind a lot of unnecessary code if MediaMTX by itself already gets me 99.99% to where I want to be.