Manchester OC Summit - Unconference Workshop about some maintenance work on the Capture Agent API

[marcusm7]

Opencast Agent API workshop during the OC Summit '26

It was suggested to do a workshop about this topic in Manchester (OC Summit 2026).
FYI: unconference planning document -> Discussion topic: Opencast standardisation of the configuration metadata for the capture agent

What features do you think are missing in the CA API?

Are you satisfied with the current Capture Agent API, or are there features you would like to see added? Which use cases are you currently unable to implement? Or are there use cases which can only be implemented with workarounds?

The question is: Should the Capture Agent specification be modified and how?

Prototype, CA API extension plans:

Some research and implementations have already been done by @Arnei @JulianKniephoff @KatrinIhler @lkiesow:

• roadmap
• planning and
• demo implementation: frontend backend

Possible Topics:

• Should a recorder inform Opencast about its capabilities and status? To achieve what goal?
  • RN there are the available capture agent inputs, only.
  • What about addidtional metadata like device type information? Extron SMPs provide them. Epiphan Nexus do not (yet).
  • Which properties are needed? Which are optional and which are mandatory?
  • Should the properties and possible values be standardized or should this be left to be decided by the manufacturer?
• What is the contract a recorder has to follow? Is the status-quo sufficient?

There are multiple channels to keep in mind for this (that I know of rn):

• (recorder -> opencast) the CA configuration endpoint which specifies informational data and recorder capabilities.
• (opencast -> recorder) the capture agent API calendar endpoint (or other devices like lecture hall controllers)
• (recorder -> opencast) the recorded data + metadata that is ingested from the recorder into opencast.
• (recorder -> opencast) agent-status endpoint

Wishlist (Uni Konstanz)

From a Opencast admin perspective, we would like to achieve certain goals:

• an event should contain metadata which then can be used to steer the various lecture hall devices with involvement into the recording process (right now we pass a json-Object in an unused text field of the event as information channel for the lecture hall controller device. That works for us, but it is quite an ugly workaround.)
• Examples:
  • Control the recorder
    • livestream on/off
    • livestream layout (side-by-side, camera, slides, pip, ...)
    • start the recording paused or record right away: personal rights - german: Recht am eigenen Bild. Some lecturers want to control when a recording starts.
    • define which channels to record (slides, camera, both?)
  • Control PTZ camera(s) and/ or tracking control systems for the camera directly or steer the lecture hall controller device (i.e. some Crestron RMC or DMPs) which in turn controls the camera
    • switch camera on/off
    • select the camera preset (i.e. wide shot, close up) or use tracking functionality
  • have capture agent details:
    • what's the capture agent's device type? firmware? - this could be used to steer how a Opencast workflow processes an ingest.
  • Other issues:
    • During event planning it is possible to define which channels to record, but it is not possible for the recorder to give feedback, which channels actual contain recorded data. The lecturer decides ad-hoc during the event whether the recording should contain slides or camera picture. At the moment manual post-processing is needed - Someone has to look at the video to decide which recorded channels actually contain data. (That's a rather complex topic, which might be out of scope for the first iteration.)

[reiferschris]

Thanks for the initiative @marcusm7

Some things from my wishlist:

• livestreams from capture agents should support what can be configured in Opencast: https://github.com/opencast/opencast/blob/develop/etc/org.opencastproject.liveschedule.impl.LiveScheduleServiceImpl.cfg#L20-L26
  • at least the mediapackageId is not available and would make livestream URLs unique, which would be neat.
• capture agents should have to report their capabilities (inputs especially) (Epiphan and Extron do, Pyca doesn't (yet?))
• capture agent capabilities should be customizable, meaning the reported capabilities can be aligned with the ingested flavor
  • possible with Epiphan,
  • potentially pyca when/if inputs added + recording start without server connection pyCA#413 or Add "inputs" support to pyCA pyCA#587 is accepted,
  • not possible with Extron, they have their Channel A/B set
• Only selected inputs from the schedule should be ingested (Epiphan does, pyca doesn't yet, Extron applies video mute (black) instead but uploads a useless video)

I also like/support your other ideas. Especially more info about the capture agents in opencast and therefore in the workflow properties would be nice. Currently, the SMPs by Extron provide lots of information, we use this in our workflows for example:
if: "('${capture.agent.vendor}' != 'Extron Electronics')" to process recordings not coming from SMPs, targeting pyca ingests ;)

[KatrinIhler]

#7114 might also be interesting for this discussion