Implement definable Inputs, pass on to recording command

[JanKoppe]

Opencast gives the user the ability to select different inputs when scheduling a recording.

pyCA should be able to define such inputs with a set of keywords, report them to opencast and pass on the selection in a scheduled recording to the recording command.

I would be willing to work on such a feature.

[JanKoppe]

We should take another look at #23 IMO. This would be be a good basis for this.

[lkiesow]

Yes, now that Opencast does support JSON for this interface, it would be worth a shot. I guess it will now be easier and less a hack like concatenating strings for building XML (which is the main reason I never merged it).

[lkiesow]

Btw, would you create a map of command lines for that?
If so, I suggest that we change the command line to a list instead of the string it is now.
That way we wouldn't split it later to pass on to Popen.
Though, that depends if we can make that work properly with configobj.

[JanKoppe]

I'd rather have the option to config a dict of [variable, title, type, filename, flavour]. Title and type will be reported to opencast (can opencast even handle different types? thinking about boolean or numeric), and substituted for the variable in the recording command.

I do appreciate the flexibility and simplicity of pyCA only launching one command with arguments that you can layout however you want. actual recording should stay out of pyCA IMO.

[JanKoppe]

Notes from a voicechat between lkiesow and me just now:

• Use newer configuration method from Opencast 2.3 onwards, don't support older XML method in <=2.2
• Some way to use jinja-style placeholders for configuration properties in the recording command would be very nice (e.g. something like {{ options.inputs.presentation }} printing true or false), but could be a huge security risk - something coming from the internet is directly pasted into a shell.
• For now keep it simple: write the configuration to a JSON file in the event directory, the user has to deal with reading and processing these options on their own.

[mpmuc84]

Question: Is this still being worked on? I would be interested in such a feature for pyCA, and would be willing to work on it as well, if this issue is still in active development.

[JanKoppe]

Hey @mpmuc84, I'm not currently working on it, neither is Lars as far as I know. So if you want to give it a try, we would appreciate it!

[mpmuc84]

Hi @JanKoppe, thanks for the quick reply!
I will try to get something together for a PR for you to consider, may take a few days, though.

If I understand your previous notes correctly, the idea was to set the capabilities to register with OC in pyCA's config, and to export this e.g. to a JSON file somewhere (location also to be set in config?) for the user's command/script to pick up and process, correct?

[JanKoppe]

Cool, thanks for taking a shot at this :)

If I understand your previous notes correctly, the idea was to set the capabilities to register with OC in pyCA's config, and to export this e.g. to a JSON file somewhere (location also to be set in config?) for the user's command/script to pick up and process, correct?

Yes, a rough overview of the aspects that would need to be implemented would be

• Allow the configuration of several inputs and corresponding tracks, maybe with some Human-friendly format (e.g. "HDMI Input 1") and a machine-readable format (e.g. "hdmi1")
• Transmit these available inputs as config option to Opencast
• Read/Parse the selected inputs from the schedule information when starting to capture
• Write out the selected inputs as some file (implementing these as parameters/args for the recording_command would probably be overcomplicating things) when starting to capture
• Ingest tracks based on the selected inputs

Maybe it would make sense to split these parts up and implement it (together?) in smaller chunks. What do you think?

[lkiesow]

…neither is Lars as far as I know

I'm not. Feel free to grab this.

Transmit these available inputs as config option to Opencast

All necessary endpoints for this should be part of the /capture-admin endpoints. By now, everything you need should support JSON as well.

Maybe it would make sense to split these parts up and implement it (together?) in smaller chunks. What do you think?

Not sure but you could start by just sending the information to Opencast. Picking them up for capture would then be part 2.

[mpmuc84]

Thanks, sounds good. :)
I would agree on splitting up the tasks for this, and I would indeed start by adding the config options and registration of inputs with OC, before proceeding to the other parts.

[slaudel]

We too would like to see this pyCA.
Is there any documentation on how the JSON has to be structured in order to send the configuration to Opencast? At https://data.lkiesow.de/opencast/docs-developer-2019-07-07/modules/capture-agent/capture-agent/#basic-rules I only found sparse documentation that does not contain any details how it should look. The best would be an example of such a JSON that one can derive from.

[lkiesow]

Interesting to see that you found a copy of the official Opencast documentation on my server :-D

I'm not sure if this is well documented. I wrote the other capture agent documentation, but since I never used the inputs, I never write that down.

For setting the inputs, you would use the REST endpoint POST /agents/{name}/configuration

Use a configuration payload like this:

{"capture.device.names":"a,b,x"}

where the a,b,x is a comma separated list of inputs.

You can just use the REST docs to set this for any capture agent:

This will then automatically show up as input fields in the admin interface:

Capture agents will then get the selection as part of the scheduling information.

If you want to work on this, please let me know. I think there are lots of things to stumble over if you like to tackle this, and you could easily waste a lot of time. It's probably easier to go through what you want to do and how you can gather information about that in a conference call.