|
|
| AEP 01 | Aufnahmen und Wiederholungen |
|
|
|
|--------|------------------------------|
|
|
|
| 2022-02-25 | Draft - Version 2 |
|
|
|
|
|
|
## EPIC
|
|
|
|
|
|
* **Recorder and Cut&Glue Components:** [\*\*https://gitlab.servus.at/aura/meta/-/issues/9 \*\*](https://gitlab.servus.at/aura/meta/-/issues/9 "[EPIC] AURA Recorder and Cut&Glue Components")
|
|
|
* **Repeating Shows & Schedules:** [**https://gitlab.servus.at/aura/meta/-/issues/15**](https://gitlab.servus.at/aura/meta/-/issues/15 "[EPIC] Repeating Shows & Schedules")
|
|
|
|
|
|
## Use Cases:
|
|
|
|
|
|
* **Automatische oder manuelle Wiederholung einer Sendung**
|
|
|
* **Download von Episoden durch Radiomachende im Dashboard**
|
|
|
* **Basis für CBA Uploader (siehe AEB 02)**
|
|
|
|
|
|
## Anforderungen und Aufgaben:
|
|
|
|
|
|
* **Engine Recorder**: Aufnahme des Audio Signals in konfigurierbaren Blöcken.
|
|
|
* **Tank Cut & Glue**: Zuschneiden und Zusammenfügen von Blöcken nach Sendungslängen (Timeslots). Das Ergebnis sind die Aufnahmen der eigentlichen Sendungen. Dieser Ansatz ermöglicht nachträgliche, individuelle Schnitte wie z.B. exkludieren von Jingles, lizenzpflichtiges Material oder ungeplante Überlängen von Sendungen.
|
|
|
* **Bündeln von Aufnahmen und Metadaten**: Speicherung der Metadaten der Sendungen (Sendereihe, Episode, Track Infos): Als Software-unabhängigen Ansatz sollen hierfür CUE Files verwendet werden. Dies ermöglicht die Darstellung von Metadaten per Icecast, RDS, Webinhalte auch für Aufnahmen weiter über die eigentlich Ausspielung hinaus. Weiters können Metadaten auch in Archiven per Texteditor „naiv“ gelesen werden.
|
|
|
* **Tank**: Bereitstellung der Aufnahmen und Metadaten
|
|
|
* **Dashboard:** <span dir="">Wenn eine Aufnahme bereit steht, den Download Button aktiveren um Radiomachenden den Download ihrer Episode zu ermöglichen</span>
|
|
|
* **Engine:** Beim Auspielen checken, ob es sich um eine Erstausspielung handelt oder um eine um Wiederholung. Im Fall einer Wiederholung _check_, ob eine Aufnahme zur Verfügung steht.
|
|
|
* **Engine Core:** Hier muss lediglich das CUE File der Aufnahme bereitgestellt werden. Darauf achten, dass die Filesystem Pfade passen. Die Metadaten an Icecast werden automatisch mitgegeben.
|
|
|
|
|
|
## Offene Punkte zur Diskussion und Nachbearbeitung:
|
|
|
|
|
|
* Wann gilt ein File als eine Aufnahme? Handhabung von _Aufnahmen von Aufnahmen von ..._ oder Aufnahmen von vorproduzierten Sendungen (aktives Exkludieren oder passives Ignorieren). Beispiele:
|
|
|
* Es könnte nämlich den Wunsch geben, dass selbst eine vorproduzierte Sendung aufgenommen werden soll, wenn diese gewisse Overlays wie Jingles enthält. Dies ist jedoch frühestens Thema für Jingle Manager.
|
|
|
* Der Unterschied „vorproduzierte Sendungs vs. Playliste aus Einzelfiles“ spielt hier auch rein, weil letzteres nicht einfach als Download angeboten werden kann, nicht in die Mediathek oder CBA Upgeloaded werden kann.
|
|
|
* **CUE Konzept generell:** Hier sind starke unterschiedliche Meinungen zu erwarten. @david: Ich sehe diesen low-level Ansatz gut, weil er vor allem unversell einsatzbar ist. Somit können auch manuell einfach Aufnahmen hinzugefügt werden, die niemals im Ausspielsystem waren, aber durch CUE trotzdem Keypoint- und Meta-Informationen verfügen. CUE wird nativ durch Liquidsoap unterstützt. Und zu guter Letzt ergibt es weniger interne Komponenten-API-Abhängigkeiten und Plattform-Agnostizismus FTW!
|
|
|
* Speichern der CUE Files bereits für Aufnahme Blöcke oder nur für geschnittene Episoden. Bei ersterem können Schnittpunkte anhand von CUE Files realisiert werden. Wiederverwendbarkeit und „Lesbarkeit“ der Aufnahme Blöcke wird auch nach Archiverung erhöht, weil eben Meta Infos zur Verfügung stehen.
|
|
|
* Wie wird die Abhängigkeit zwischen verfügbaren Aufnahmen im Tank und Wiederholungs-Schedule in Steering nachvollzogen? Kann hier Engine alleine mit verfügbaren Infos entscheiden was genommen wird?
|
|
|
* Review der Wiederholungs Optionen in Steering und Dashboard (laaang ist es her…)
|
|
|
* <span dir="">Tank und Steering:</span> Muss Steering wissen, dass es eine Aufnahme gibt? Dies Aktiviert die Möglichkeit die Episode als Wiederholung auszuspielen. Reicht es, wenn es Dashboard weiß?
|
|
|
* Möglicherweise unnötiges Transcoding vermeiden oder konfigurierbar machen. Wann ja und wann nein?
|
|
|
* Wenn eine Aufnahme im Tank bereit steht, braucht es ein Event an Dashboard? Websocket?
|
|
|
|
|
|
##
|
|
|
|
|
|
## Details pro Komponente
|
|
|
|
|
|
###
|
|
|
|
|
|
---
|
|
|
|
|
|
### Engine Recorder
|
|
|
|
|
|
Entwicklung einer neuen Python Komponente <span dir="">`engine-recorder`</span> um blockweise Aufnahmen zu erstellen.
|
|
|
|
|
|
**Konfigurationsoptionen**:
|
|
|
|
|
|
* Audio Settings (Device, Qualität usw.)
|
|
|
* Die Blocklänge ist konfigurierbar (Default 1h).
|
|
|
* Automatische Löschung von Aufnahmen die älter als ein konfigurierbares Datum sind.
|
|
|
* Aufnahmen können optional per <span dir="">rsync</span> Skript intern archiviert werden.
|
|
|
* Abstände der „Schneidezyklen“, also wie oft der Dienst nach neuen Aufnahme Blöcken checkt und diese zu Sendungen zuschneidet. Ein Beispiel findet sich in <span dir="">engine-api</span>
|
|
|
|
|
|
**Low-Level API:** <span dir="">Kommunikation mit Cut & Glue mittels Filesystem. </span>Die Aufnahmen werden in einem <span dir="">`$AUDIO_STORE/recordings/block` Folder des Audio Stores bereitgestellt. Das Namensschema der Files ermöglicht der Cut & Glue Komponente die gewünschten Aufnahmen zu „entdecken“.</span>
|
|
|
|
|
|
**Deployment Szenarien:** In einem einfachen Deployment wird der Recorder auf der selben Instanz wie Engine und Engine Core deployed. Somit müssen sich die Komponenten die Audio Devices teilen. Hier soll per ALSA ein kombiniertes, virtuelles _Composite Audio Devices_ konfiguriert werden. Wenn der Recorder wiederum auf einer eigenständigen Instanz deployed wird, kann direkt auf ein ALSA Device zugegriffen werden.
|
|
|
|
|
|
**Sound System Support:** Erstmal nur ALSA.
|
|
|
|
|
|
**Docker und Docker Compose:** Das Service soll als Docker Container bereitgestellt werden. Das Docker Compose „Aura Playout“ soll so erweitert werden, dass das Service optional mit-deployed werden kann (oder optional nicht mit-deployed werden kann). Update der Dokumentation im META Repository. <span dir="">Update der Diagramme für Deployment Scenarios.</span>
|
|
|
|
|
|
… **_to be defined ..._**
|
|
|
|
|
|
###
|
|
|
|
|
|
---
|
|
|
|
|
|
### Tank Cut & Glue
|
|
|
|
|
|
Entwicklung einer neuen Python Komponente <span dir="">`tank-cut-glue`</span> um aus den Aufnahme Blöcken aus <span dir="">`engine-recorder`</span> konkrete Sendungslängen zuzuschneiden. Die Komponente soll als User Agent ausgeführt werden.
|
|
|
|
|
|
**Authentifizierung**: Cut & Glue authentifiziert sich gegen Tank per _Bearer Token_ (vgl. Implementierung in <span dir="">`engine`</span>)
|
|
|
|
|
|
**Kernlogik:**
|
|
|
|
|
|
1. In konfigurierten Abständen Check ob neue Aufnahmen nach dem definierten Namensschema vorliegen (Filesystem)
|
|
|
2. Auslesen des Timeslots per Steering API
|
|
|
3. <span dir="">Cut & Glue mit FFMPEG (POC siehe unten), entsprechende Aufnahmeblöcke aus $AUDIO_STORE/recordings/block</span>
|
|
|
4. <span dir="">Speichern des Episoden Files in `$AUDIO_STORE/recordings/show`</span>
|
|
|
5. Triggern eines Imports nach Tank
|
|
|
6. Notification an Dashboard (?)
|
|
|
|
|
|
**_\
|
|
|
… to be defined …_**
|
|
|
|
|
|
**<span dir="">Docker und Docker Compose:</span>** <span dir="">Das Service soll als Docker Container bereitgestellt werden. Das Docker Compose „Aura Web“ soll so erweitert werden, dass das Service optional mit-deployed werden kann (oder optional nicht mit-deployed werden kann). Update der Dokumentation im META Repository. Update der Diagramme für Deployment Scenarios.</span>
|
|
|
|
|
|
Nachstehend finden sich zwei Proof of Concepts mit FFMPEG und SOX. Wenn möglich sollte FFMPEG bevorzugt werden, da es besseren Support bietet und ohnehin an anderen Stellen in der Toolchain verwendet wird.
|
|
|
|
|
|
**Proof of Concept mit FFMPEG**
|
|
|
|
|
|
Schneiden:
|
|
|
|
|
|
`ffmpeg -i `[`https://live.helsinki.at:8088/live160.ogg`](https://live.helsinki.at:8088/live160.ogg)` -codec flac -f segment -segment_atclocktime 1 -segment_time 600 -strftime 1 "%Y-%m-%d/%s.flac"`
|
|
|
|
|
|
Mehr Infos zum FFMPEG Segment Muxer: <https://ffmpeg.org/ffmpeg-formats.html#toc-segment_002c-stream_005fsegment_002c-ssegment>
|
|
|
|
|
|
#### **Proof of Concept mit SOX**
|
|
|
|
|
|
Schneiden:
|
|
|
|
|
|
`` sox input.flac chopped/output.flac trim 0 10 : newfile : restart` ``
|
|
|
|
|
|
`ls chopped output001.flac output003.flac output005.flac output007.flac output009.flac output011.flac output013.flac output015.flac output017.flac output019.flac output021.flac output023.flac output025.flac output027.flac output029.flac output031.flac output002.flac output004.flac output006.flac output008.flac output010.flac output012.flac output014.flac output016.flac output018.flac output020.flac output022.flac output024.flac output026.flac output028.flac output030.flac`
|
|
|
|
|
|
Concatten mit μs genauem Längenvergleich:
|
|
|
|
|
|
`sox chopped/* final.flac`
|
|
|
|
|
|
`A=$(soxi -D input.flac) `\
|
|
|
`B=$(soxi -D final.flac)`\
|
|
|
`echo "INPUT: $A ---vs--- $B :OUTPUT"`\
|
|
|
`INPUT: 307.600000 ---vs--- 307.600000 :OUTPUT`
|
|
|
|
|
|
###
|
|
|
|
|
|
---
|
|
|
|
|
|
### Tank
|
|
|
|
|
|
Die Aufnahme soll möglichst zeitnah nach einer Sendung bereitstehen für
|
|
|
|
|
|
* <span dir="">Schedulen einer Wiederholung</span>
|
|
|
* <span dir="">Download via Dashboard</span>
|
|
|
* Upload CBA
|
|
|
|
|
|
… **_to be defined …_**
|
|
|
|
|
|
###
|
|
|
|
|
|
---
|
|
|
|
|
|
### Steering
|
|
|
|
|
|
_Hackathon Freistadt Juli 2021: Im Moment ist bei Wiederholungen nicht erkennbar, was wiederholt wird (aktuell: die letzte Episode der Reihe, die keine Wiederholung war). (Implizite Logik)\
|
|
|
In Zukunft wird das explizit angegeben. (Kein UI-Feld, sondern intern)_
|
|
|
|
|
|
… **_to be defined …_**
|
|
|
|
|
|
###
|
|
|
|
|
|
---
|
|
|
|
|
|
### Dashboard
|
|
|
|
|
|
Das Dashboard soll verschiedene Varianten an Wiederholungskonzepten anbieten:
|
|
|
|
|
|
* **Variante 1:** Sendungen werden nach einem Wiederholungsmuster aus der "Schedule" automatisch wiederholt. Hierbei wird immer die letzte Sendung genommen die nicht als Wiederholung ausgezeichnet wurde (https://gitlab.servus.at/aura/dashboard/-/issues/39)
|
|
|
* **<span dir="">Variante 2:</span>**<span dir=""> Vergleiche Steering: UI Implementierung für die Möglichkeit Sendungen als Wiederholung zu Schedulen (</span>https://gitlab.servus.at/aura/dashboard/-/issues/63<span dir="">).</span>
|
|
|
* **Variante 3:** Sendungen sollen im EmissionManager oder Kalender manuell als Wiederholungs gescheduled werden (ähnlichg zu Fall1 nur, dass dir nix raufgeladen werden muss. Es wird hier automatisch das richtige Recording der Sendung verwendet. Dies könnte auch für altere Sendungen, nicht nur die letzte möglich gemacht werden (https://gitlab.servus.at/aura/dashboard/-/issues/64).
|
|
|
|
|
|
… **_to be defined …_**
|
|
|
|
|
|
###
|
|
|
|
|
|
---
|
|
|
|
|
|
### **_Engine_**
|
|
|
|
|
|
… **_to be defined …_**
|
|
|
|
|
|
###
|
|
|
|
|
|
---
|
|
|
|
|
|
### Engine Core
|
|
|
|
|
|
… **_to be defined …_** |
|
|
\ No newline at end of file |