Wer schon einmal ein Video in Opencast hochgeladen hat - sei es über ein Learning-Management-System (LMS) oder direkt in der Nutzeroberfläche von Opencast - wird nach dem Upload eine Meldung erhalten haben: "Das Video befindet sich nun in einer Verarbeitung/Konvertierung." Diese Verarbeitung kann, abhängig von der Dateigröße und der Ausstattung des Servers, einige Zeit in Anspruch nehmen. Erst nach erfolgreichem Abschluss erscheint das fertige Video in der jeweiligen Übersicht und lässt sich abspielen.
Abgesehen von der initialen Meldung bekommen Nutzende normalerweise nicht viel von den einzelnen Schritten mit, die während der Verarbeitung abgearbeitet werden. Meist werden die vielen verschiedenen Operationen, die während der Verarbeitung im Hintergrund angewendet wurden, erst beim Abspielen deutlich. Das sind dann zum Beispiel das Erscheinen von Untertiteln, Vorschaubildern oder verschiedener Qualitätsstufen, die das fertige Video erst rund machen.
Aber wie genau funktioniert der ganze Ablauf eigentlich? Welche Operationen gibt es? Wie kann man sie definieren und an seine eigenen Bedürfnisse anpassen?
Hier kommen die sogenannten Workflows ins Spiel. Mit ihrer Hilfe lassen sich die einzelnen Schritte der Verarbeitung genauestens definieren und anpassen. Opencast wird bereits mit einer Reihe von Standard-Workflows ausgeliefert, die schon einen Teil des Funktionsumfangs zeigen und abdecken. Oftmals wünschen sich Institutionen aber weitere Funktionen oder eine individuelle Gestaltung der Videos. Das kann durch Anpassungen an bestehende oder durch Erstellung ganz neuer Workflows umgesetzt werden. Aber nicht nur nach dem initialen Upload kommen Workflows zum Einsatz. Auch auf bereits bestehende Videos können Workflows für verschiedenste Zwecke angewendet werden. Beispielsweise für das Löschen von Videos, Erstellen von automatischen Untertiteln, Aktualisierung der Metadaten und viele mehr.
Im Folgenden möchte ich euch anhand des Standard-Upload-Workflows von Opencast einen Einblick in den grundlegenden Aufbau und die Funktionsweise von Workflows geben. So bekommt ihr einen Eindruck davon, was es für Möglichkeiten gibt und wie ihr beginnen könnt, eigene Workflows zu erstellen.
Ein Workflow kann entweder im xml oder yaml-Format angelegt werden und muss im workflows Ordner eurer Opencast Installation abgelegt werden. Im Wesentlichen besteht er aus einer Aneinanderreihung von Operationen bzw. Workflow Operation Handlern (WOH). Um Verwirrungen zu vermeiden, bleibe ich im Folgenden dabei, die WOHs "Operationen" zu nennen. Mittlerweile gibt es eine Auswahl von über 100 Operationen, die zur Erstellung von Workflows genutzt werden können. Jede von ihnen erfüllt einen speziellen Zweck - Tendenz steigend.
Schauen wir uns einmal anhand der encode-Operation Schritt für Schritt an, wie eine Operation im Allgemeinen aufgebaut ist:
- id: encode
fail-on-error: true
exception-handler-workflow: "partial-error"
description: "Encoding video"
configurations:
- source-flavor: "*/source"
- target-flavor: "*/preview"
- target-tags: "engage-download,engage-streaming,rss,atom"
- encoding-profile: "fast.http"Jede Operation hat eine eindeutig festgelegte id , die in der jeweiligen Dokumentation zu finden ist.
Mit fail-on-error wird festgelegt, ob der gesamte Workflow fehlschlägt, wenn es bei der Abarbeitung der Operation einen Fehler gibt. Alternativ wird die Operation lediglich übersprungen.
Mit dem exception-handler-workflow hat man die Möglichkeit, die id eines anderen Workflows anzugeben, der bei einem Fehler angestoßen werden soll. So sichert man zum Beispiel den aktuellen Stand der Daten.
Die description gibt eine kurze Beschreibung der Operation, um es zu veranschaulichen.
Die zuvor genannten Einstellungen können für jede Operation auf die gleiche Art und Weise definiert werden. Zu Unterschieden kommt es meist erst in den individuellen configurations:
In sehr vielen Operationen findet man eine Angabe des source-flavor und des target-flavor . Flavors werden in Opencast genutzt, um den aktuellen Stand eines Videoelementes zu verfolgen. So können wir den Ablauf des Workflows möglichst genau kontrollieren: Zu Beginn wird ein Video hochgeladen und z.B. mit dem Flavor presentation/source versehen, um zu kennzeichnen, dass es sich um das Ursprungsvideo handelt.
Als nächstes kommt beispielsweise die oben gezeigte encode Operation, in der aus dem Ursprungsvideo ein kleines Vorschauvideo generiert wird. Um dieses zu kennzeichnen, wird dann für das neue Vorschauvideo der Flavor von presentation/source zu presentation/preview umgeschrieben, mit welchem wiederum nachfolgende Operationen weiterarbeiten können. Das Sternchen in dem obigen Beispiel dient als Platzhalter, da in Opencast auch mehrere Videos zusammen hochgeladen werden können. Diese werden dann jeweils mit presenter/source bzw. presentation/source gekennzeichnet. Mit dem Sternchen werden dann alle Elemente betrachtet, deren Flavor auf /source endet. Jedes Videoelement sollte immer genau einen Flavor besitzen.
Ähnlich zu den Flavors gibt es außerdem noch Tags, die in vielen Operationen als source-tags und/oder target-tags angegeben werden können. Diese dienen zwar ebenfalls dem Zweck Videoelemente zu kennzeichnen, können aber freier eingesetzt werden. Zum Beispiel können einem Videoelement mehrere Tags zugewiesen werden, welche dann wiederum von verschiedenen anderen Operationen aufgegriffen werden können.
Es gibt je nach Operation diverse weitere Konfigurationsmöglichkeiten, die in der jeweiligen Dokumentation beschrieben werden. Im obigen Beispiel wird mit dem encoding-profile festgelegt, welches hinterlegte Profil zur Kodierung des Videos genutzt werden soll.
Gehen wir nun dazu über, uns den Aufbau eines kompletten Workflows genauer anzuschauen. Zu Beginn des Workflows werden noch allgemeine Informationen und Konfigurationsmöglichkeiten definiert. Schauen wir uns ein Beispiel anhand von Auszügen des Standard-Upload-Workflows "Process upon upload and schedule" an. Zur besseren Lesbarkeit wird das yaml-Format verwendet. Der vollständige Workflow im xml-Format lässt sich im offiziellen GitHub Repository finden.
---
id: schedule-and-upload
title: Process upon upload and schedule
tags:
- upload
- schedule
displayOrder: 100
description: |-
The default workflow for processing media.
If straight to publishing is checked, then the uploaded media will be published without cutting.Die id kann frei gewählt werden, muss jedoch einzigartig sein, damit Opencast den Workflow korrekt erkennt.
Der titel wiederum kann komplett frei gewählt werden und definiert, unter welchem Namen der Workflow in den Nutzeranzeigen erscheint.
Die tags geben an, wo der Workflow angezeigt wird, also beispielsweise im Upload Formular, im Editor oder beim Planen von Videoaufzeichnungen. Sie können auch komplett ausgelassen werden, damit der Workflow gar nicht direkt von Nutzenden ausgewählt werden kann. Intern kann er, wie wir später noch sehen werden, dann trotzdem durch andere Workflows eingebunden und verwendet werden.
Die displayOrder bestimmt die Reihenfolge, in der die Workflows angezeigt werden.
Letztlich wird über die description eine kurze Beschreibung des Workflows für die Nutzenden gegeben.
configuration_panel_json: |-
[{
"fieldset": [
{
"type": "checkbox",
"name": "straightToPublishing",
"label": "Straight to publishing",
"value": true
}
]
}]Im nächsten Abschnitt werden die Konfigurationen des Workflows definiert. Das kann hilfreich sein, damit Nutzende die Möglichkeit haben, optionale Verarbeitungsschritte auszuführen. In diesem Fall kann Nutzer durch eine Checkbox bestimmen, ob das Video direkt veröffentlicht wird. Alternativ bleibt es zunächst unveröffentlicht, um es beispielsweise vorher noch im Editor zu bearbeiten.
Die gesetzte Variable straightToPublishing können wir in späteren Operationen aufgreifen und nutzen. So bestimmen wir, ob wir die jeweilige Operation ausführen
Als nächstes werden die einzelnen Operationen aneinandergereiht, damit am Ende ein Workflow entsteht. Eine kleine Auswahl zentraler Operationen wird in den folgenden Beispielen genauer vorgestellt. Für weiterführende Informationen können jeweils der entsprechende Abschnitt der Opencast Dokumentation sowie die Kommentare innerhalb der originalen Workflows betrachtet werden.
- id: snapshot
fail-on-error: true
exception-handler-workflow: "partial-error"
description: "Archive raw recording after ingest"
configurations:
- source-tags: "archive"Eine der wichtigsten Operationen ist snapshot . Damit lassen sich alle Videoelemente, die in diesem Fall zuvor mit dem Tag archive gekennzeichnet wurden, archivieren und somit sichern. Das macht sich später bemerkbar, wenn beispielsweise eine Version des Ursprungsvideos benötigt wird. Diese können wir für Neuverarbeitungen gebrauchen oder, um bereits verarbeitete Elemente zu sichern. Vorsicht: Alle Elemente, die nicht während des Workflows archiviert oder veröffentlicht werden, gehen nach Abschluss des Workflows verloren!
- id: include
if: "${straightToPublishing}"
description: "Publish the recording"
configurations:
- workflow-id: "partial-publish"Wie bereits erwähnt, lassen sich auch andere Workflows durch Operationen mit einbeziehen. Das kann eine gewisse Struktur im Aufbau gewährleisten, sodass häufige Abfolgen von Operationen erneut verwendet werden können. Im obigen Beispiel werden der Workflow partial-publish und damit alle enthaltenen Operationen berücksichtigt. Wir können außerdem sehen, wie die Variable straightToPublishing, die zuvor am Beginn des Workflows definiert wurde, verwendet wird. Sollte der Nutzer ausgewählt haben, dass das Video nicht direkt veröffentlicht wird, wird dieser Schritt komplett übersprungen.
- id: publish-engage
max-attempts: 2
exception-handler-workflow: "partial-error"
description: "Publishing to Opencast Media Module"
configurations:
- download-source-flavors: "dublincore/*,security/*"
- download-source-tags: "engage-download"
- streaming-source-tags: "engage-streaming"
- check-availability: falseWird der partial-publish Workflow eingebunden, sehen wir nach diversen weiteren Operationen zur Verarbeitung am Ende die publish-engage Operation. Diese ist essenziell, um alle zuvor verarbeiteten Videoelemente zu publizieren. So können sie im PaellaPlayer, der in Opencast genutzt wird, abgespielt und ggf. heruntergeladen werden. Die Tags und Flavors werden erneut genutzt, um anzugeben, welche der zuvor verarbeiteten Elemente wohin publiziert werden sollen.
Wie bereits erwähnt, war dies nur eine kleine Auswahl der Operationen, die in den Workflows genutzt werden. Ihr solltet aber nun das nötige Wissen besitzen, um selbst anzufangen, Workflows zu modifizieren oder sogar komplett neu zu schreiben. Workflows sind mächtige Werkzeuge, um den Funktionsumfang von einer Standard-Opencast Installation zu vergrößern und den eigenen Bedürfnissen anzupassen. Es lohnt sich, einen Blick auf die Liste der verfügbaren Operationen zu werfen. Hier bekommt ihr einen Überblick über alle weiteren Möglichkeiten.
FunFact: Wie in dieser Präsentation gezeigt wurde, sind Opencast Workflows tatsächlich sogar Turing-vollständig. Das heißt, sie können theoretisch als Programmiersprache dienen und jede andere Turing-vollständige Maschine emulieren. Empfehlenswert ist dies aber eher nicht.
Zuletzt sei noch gesagt, dass es, besonders bei komplexeren Funktionen, nicht immer leicht fällt, sofort einen perfekten, lauffähigen Workflow zu schreiben. Ich empfehle, mit den Standard-Workflows anzufangen und Schritt für Schritt Änderungen vorzunehmen. Wichtig: Zwischendurch testen und falls nötig, die Fehlermeldungen in den Log-Dateien oder der Opencast Admin-UI untersuchen.
Falls es doch mal zu kompliziert wird - Ein Fehler wird nicht gefunden oder ihr braucht eine ganz neue Operation: Der elan e.V. bietet natürlich auch Unterstützung an. Über unser Kontakt-Formular könnt ihr euch gerne jederzeit für ein Beratungsgespräch und ggf. weitere Unterstützung melden.
Viel Spaß beim Ausprobieren!
