... | ... | @@ -4,12 +4,13 @@ |
|
|
| 2022-03-11 | Details zu Tank & Steering | Ernesto | Draft |
|
|
|
| 2022-05-04 | Erstes Team Review | Ernesto, Christian, Ole, David | Draft |
|
|
|
| 2022-05-31 | Referenz zu Epic | David | Draft |
|
|
|
| 2022-11-17 | Update offene Punkte, Tank spec | David | Draft |
|
|
|
|
|
|
## EPIC
|
|
|
|
|
|
[\[EPIC\] \[AEP01\] Recording, cutting and rescheduling of shows)](https://gitlab.servus.at/aura/meta/-/issues/97 "[EPIC] [AEP01] Recording, cutting and rescheduling of shows")
|
|
|
|
|
|
## Use Cases:
|
|
|
## Anwendungsfälle:
|
|
|
|
|
|
* **Automatische oder manuelle Wiederholung einer Sendung**
|
|
|
* **Download von Episoden durch Radiomachende im Dashboard**
|
... | ... | @@ -20,7 +21,7 @@ |
|
|
* **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
|
|
|
* **Tank**: Bereitstellung der Aufnahmen und Metadaten; Abbilden der Relation zwischen Episode/Timeslot und Aufnahme
|
|
|
* **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.
|
... | ... | @@ -30,17 +31,15 @@ |
|
|
* 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?
|
|
|
* <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ß?
|
|
|
* Wenn eine Aufnahme im Tank bereit steht, braucht es ein Event an Dashboard? Websocket?
|
|
|
* **Was ist der treibende Dienst:** Bisher gehen wir von einem Ansatz aus, dass Cut&Glue für den Export der Aufnahmen nach Tank verantwortlich ist. Wie sollen hier Outages des Cut&Glue Services behandelt werden? Ist hier Cut&Glue in der Verantwortung, dass diese Nachgereit werden oder holt sich diese Tank je nach Bedarf? In einer idealen Architektur würde ich sagen, das Tank über seine Wahrheit bescheid weiß und für seine "innerliche Integrität" selbst sorgt. Somit bei externen Diensten nachfragt, wenn er was braucht. Dies wirft jedoch das grundlegende Import/Export Konzept durcheinander.
|
|
|
|
|
|
##
|
|
|
|
|
|
## Details pro Komponente
|
|
|
## Details per Komponente
|
|
|
|
|
|
###
|
|
|
|
... | ... | @@ -66,8 +65,6 @@ Entwicklung einer neuen Python Komponente <span dir="">`engine-recorder`</span> |
|
|
|
|
|
**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 ..._**
|
|
|
|
|
|
###
|
|
|
|
|
|
---
|
... | ... | @@ -85,12 +82,8 @@ Ein erster Komponenten Entwurf sieht wie folgt aus: ![Component_Diagram_cut_glue |
|
|
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 …_**
|
|
|
4. <span dir="">Speichern des Episoden Files in `$AUDIO_STORE/recordings/show`</span>. Neben den Audiofiles sollen auch CUE sheets im selben Namensschema gespeichert werden.
|
|
|
5. Triggern eines Imports nach Tank inkl. CUE sheets. Wichtig ist hier das Aufnahmen beim import nicht normalisiert werden und der Import per Filesystem erfolgt (anstatt HTTP)
|
|
|
|
|
|
**<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>
|
|
|
|
... | ... | @@ -108,13 +101,13 @@ Mehr Infos zum FFMPEG Segment Muxer: https://ffmpeg.org/ffmpeg-formats.html#toc- |
|
|
|
|
|
Schneiden:
|
|
|
|
|
|
`sox input.flac chopped/output.flac trim 0 10 : newfile : restart\``
|
|
|
\`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`
|
|
|
`sox chopped/\\\\\\\* final.flac`
|
|
|
|
|
|
`A=$(soxi -D input.flac)` \
|
|
|
`B=$(soxi -D final.flac)`\
|
... | ... | @@ -129,9 +122,15 @@ Concatten mit μs genauem Längenvergleich: |
|
|
|
|
|
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
|
|
|
* das <span dir="">Schedulen einer Wiederholung</span>
|
|
|
* den <span dir="">Download via Dashboard</span>
|
|
|
* den Upload zur CBA
|
|
|
|
|
|
Aufnahmnen werden durch einen Cut&Glue Agent regelmäßig und automatisiert nach Tank importiert.
|
|
|
|
|
|
Hier braucht es eine Erweiterung der Tank API, damit zu Aufnahmen auch Metainformation hinzugefügt werden können (vgl. CUE sheets die durch Cut&Glue bereitgestellt werden). Diese CUE sheets sind im Datenmodell als "stringified, validiertes JSON" definiert (siehe \[AEP05 - Abschnitt Tank\](https://gitlab.servus.at/aura/aura/-/wikis/AEP05-Erweiterung-Datenmodell)).
|
|
|
|
|
|
**Offen**: Woher weiß das Dashboard, dass eine Aufnahme zur verfügung steht. Reicht vorerst ein Refresh? In Zukunft wären WebSockets gut.
|
|
|
|
|
|
… **_to be defined …_**
|
|
|
|
... | ... | |