events:cccamp15:pp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
events:cccamp15:pp [2018/04/23 15:28] – derpeterevents:cccamp15:pp [2026/07/26 22:17] (current) – external edit 127.0.0.1
Line 1: Line 1:
-= CCCamp15 Recording / Postprocessing+# CCCamp15 Recording / Postprocessing
  
  
 Kurzer Abriss der Pipeline, streng chronologisch: Kurzer Abriss der Pipeline, streng chronologisch:
  
-== Capturing+## Capturing
  
 Auf Encoder-Cubes im jeweiligen Raum, auf dedizierter SDI-Karte (T-Stück oder zweiter BiMi-Ausgang) mit ffmpeg-Zeile. Tools: **sdi-run** und **ffmpeg** mit entsprechendem Profil (saalN-hd-direct-recording) Auf Encoder-Cubes im jeweiligen Raum, auf dedizierter SDI-Karte (T-Stück oder zweiter BiMi-Ausgang) mit ffmpeg-Zeile. Tools: **sdi-run** und **ffmpeg** mit entsprechendem Profil (saalN-hd-direct-recording)
  
 Segmentierte Aufnahmen landen in <code>/video/{{ room_fahrplan_name | lower | replace(' ', '') }}-%t-%05d.ts</code> Segmentierte Aufnahmen landen in <code>/video/{{ room_fahrplan_name | lower | replace(' ', '') }}-%t-%05d.ts</code>
-== Transfer+## Transfer
  
 "Lazy rsync" von Cubes auf VOC-Storage nach /video/cccamp15/capture/$raum. Läuft auf dem Storage und pullt von den Cubes. Achtung: wenn man mal wieder Pausen löscht oder non-stop aufgezeichnete Nächte oder so, wegen Speicherplatz... dann **immer auch und zuerst** auf dem Cube löschen! Tools: **screen** oder **sdi-run**  "Lazy rsync" von Cubes auf VOC-Storage nach /video/cccamp15/capture/$raum. Läuft auf dem Storage und pullt von den Cubes. Achtung: wenn man mal wieder Pausen löscht oder non-stop aufgezeichnete Nächte oder so, wegen Speicherplatz... dann **immer auch und zuerst** auf dem Cube löschen! Tools: **screen** oder **sdi-run** 
  
-== Fusemounts+## Fusemounts
  
 Script A, B und C laufen auf dem VOC Storage, und bauen die Fusemounts nach ''/video/fuse/cccamp15/$raum/$id'' [sic!]. Das VOC-Storage gibt ''/video'' per CIFS frei.  Script A, B und C laufen auf dem VOC Storage, und bauen die Fusemounts nach ''/video/fuse/cccamp15/$raum/$id'' [sic!]. Das VOC-Storage gibt ''/video'' per CIFS frei. 
Line 21: Line 21:
 Tools: **screen**, **fuse-ts**, **samba** Tools: **screen**, **fuse-ts**, **samba**
  
-== Schnitt+## Schnitt
  
 $Mensch mountet per CIFS vom VOC-Storage das /video an: $Mensch mountet per CIFS vom VOC-Storage das /video an:
Line 38: Line 38:
 <bootnote warning>Es muss **unbedingt** mit VLC die ''uncut.ts'' Datei geöffnet werden, um die Audiospuren auf ihre Sprache zu prüfen (Hotkey: 'b'). Die Sprache muss korrekt im Webinterface vom Tracker eingetragen werden, KDEnlive spielt **immer nur die erste Spur!**</bootnote> <bootnote warning>Es muss **unbedingt** mit VLC die ''uncut.ts'' Datei geöffnet werden, um die Audiospuren auf ihre Sprache zu prüfen (Hotkey: 'b'). Die Sprache muss korrekt im Webinterface vom Tracker eingetragen werden, KDEnlive spielt **immer nur die erste Spur!**</bootnote>
  
-== Master-Encoding+## Master-Encoding
  
 Auf den Encodern (2x Minion, ggf. 1-2 Mischerlaptops und weitere) läuft Script D und E. Zugriff auf Videodaten per r/w CIFS-Mount vom VOC-Storage. Hier liegen auch die Intros/Outro(s), die manuell erzeugt, konvertiert und abgelegt wurden. Auf den Encodern (2x Minion, ggf. 1-2 Mischerlaptops und weitere) läuft Script D und E. Zugriff auf Videodaten per r/w CIFS-Mount vom VOC-Storage. Hier liegen auch die Intros/Outro(s), die manuell erzeugt, konvertiert und abgelegt wurden.
Line 61: Line 61:
 Im Tracker ist ein Filter an der Worker Group eingerichtet, so dass die Encoder in Mildenberg nur die Master-Encoding-Tickets erhalten. Tools: **ffmpeg** Im Tracker ist ein Filter an der Worker Group eingerichtet, so dass die Encoder in Mildenberg nur die Master-Encoding-Tickets erhalten. Tools: **ffmpeg**
  
-== Check+## Check
  
 Analog Schnitt Analog Schnitt
  
-== Postprocessing Master-Encoding-Tickets+## Postprocessing Master-Encoding-Tickets
  
 Die "Master-Files" werden im Postprocessing-Schritt in die FhG Cloud (Storage Node) hochgeladen, dazu wird Script F benutzt. Auf Grund der nötigen Tracker-Filter läuft der Einfachheit halber dieses Script auf einem oder mehreren Encodern statt auf dem Storage. Tools: **scp** Die "Master-Files" werden im Postprocessing-Schritt in die FhG Cloud (Storage Node) hochgeladen, dazu wird Script F benutzt. Auf Grund der nötigen Tracker-Filter läuft der Einfachheit halber dieses Script auf einem oder mehreren Encodern statt auf dem Storage. Tools: **scp**
  
-== Releasing Master-Files+## Releasing Master-Files
  
 Die Master-Files werden in der FhG-Cloud abgelegt und dort vom Python Uploadskript nach YT und media released. Für letzteres ist ein HTTP-Zugriff von media auf den FhG Storage Node nötig. Das Uploadskript nutzt eine Worker Group **ohne** Filter, da alle Files von der gleichen Stelle (FhG Cloud) released werden. Die Master-Files werden in der FhG-Cloud abgelegt und dort vom Python Uploadskript nach YT und media released. Für letzteres ist ein HTTP-Zugriff von media auf den FhG Storage Node nötig. Das Uploadskript nutzt eine Worker Group **ohne** Filter, da alle Files von der gleichen Stelle (FhG Cloud) released werden.
  
-== Encoding Slave-Tickets+## Encoding Slave-Tickets
  
 Das Encoding der Slave-Tickets findet mit Script D und E auf verschiedenen VMs in der FhG Cloud statt. Der Storage Node stellt ''/video'' per NFS zur Verfügung. Idealerweise arbeiten die Scripte unprivilegiert und mit einem anderen User, als der Upload im Postprocessing-Schritt. Zusammen mit einem sticky bit am Verzeichnis ''/video/cccamp15/encoded'' kann verhindert werden, dass durch die Encoder die Master-Files verändert werden. Das Encoding der Slave-Tickets findet mit Script D und E auf verschiedenen VMs in der FhG Cloud statt. Der Storage Node stellt ''/video'' per NFS zur Verfügung. Idealerweise arbeiten die Scripte unprivilegiert und mit einem anderen User, als der Upload im Postprocessing-Schritt. Zusammen mit einem sticky bit am Verzeichnis ''/video/cccamp15/encoded'' kann verhindert werden, dass durch die Encoder die Master-Files verändert werden.
  
-== Check Slave-Tickets+## Check Slave-Tickets
  
 Zum Checken der Slave-Tickets muss ein Zugriff vom Camp-Gelände auf ''/video/cccamp15/encoded/'' in der FhG-Cloud möglich sein. Dieser ist aber bereits (per HTTP) für das Releasing auf media nötig und kann somit dafür verwendet werden.  Zum Checken der Slave-Tickets muss ein Zugriff vom Camp-Gelände auf ''/video/cccamp15/encoded/'' in der FhG-Cloud möglich sein. Dieser ist aber bereits (per HTTP) für das Releasing auf media nötig und kann somit dafür verwendet werden. 
Line 84: Line 84:
 FIXME Eine Einschränkung auf IP-Bereiche und/oder Basic Auth ist evtl. sinnvoll. FIXME Eine Einschränkung auf IP-Bereiche und/oder Basic Auth ist evtl. sinnvoll.
  
-== Postprocessing Slave-Tickets+## Postprocessing Slave-Tickets
  
 Da die Slave-Files bereits an der richtigen Stelle in der FhG-Cloud liegen, ist kein Postprocessing nötig. Ein "Dummy-Skript" sorgt dafür, dass die Tickets diesen Status automatisch durchlaufen. Auch hier wird dieses Skript auf Grund des nötigen Tracker-Filters auf einer oder mehreren VMs in der FhG-Cloud laufen. Da die Slave-Files bereits an der richtigen Stelle in der FhG-Cloud liegen, ist kein Postprocessing nötig. Ein "Dummy-Skript" sorgt dafür, dass die Tickets diesen Status automatisch durchlaufen. Auch hier wird dieses Skript auf Grund des nötigen Tracker-Filters auf einer oder mehreren VMs in der FhG-Cloud laufen.
  
-== Releasing Slave-Files+## Releasing Slave-Files
  
 Komplett identisch zu Master-Files Komplett identisch zu Master-Files
  
-== Reparaturprozess, allgemein+## Reparaturprozess, allgemein
  
 Es gibt zwei Stellen, an denen reparierte Aufzeichnungen halbwegs elegant in die Pipeline eingeschleust werden können: Es gibt zwei Stellen, an denen reparierte Aufzeichnungen halbwegs elegant in die Pipeline eingeschleust werden können:
  
-=== Variante 1: geändertes Quellmaterial+### Variante 1: geändertes Quellmaterial
  
 Das reparierte Material wird im gleichen Format wie das Capture zur Verfügung gestellt, also MPEG2-TS mit 4 Audiospuren etc.pp. Dabei wird im Prozess zwar noch vor dem Schnitt eingesetzt, ein Abstecken mit KDEnlive erfolgt aber **nicht** nochmal. Das Material sollte also bereits zugeschnitten sein. Allerdings darf das ersetzte Material **nicht** bereits Intro oder Outro beinhalten, da dies beim Encoding angefügt wird. Das reparierte Material wird im gleichen Format wie das Capture zur Verfügung gestellt, also MPEG2-TS mit 4 Audiospuren etc.pp. Dabei wird im Prozess zwar noch vor dem Schnitt eingesetzt, ein Abstecken mit KDEnlive erfolgt aber **nicht** nochmal. Das Material sollte also bereits zugeschnitten sein. Allerdings darf das ersetzte Material **nicht** bereits Intro oder Outro beinhalten, da dies beim Encoding angefügt wird.
Line 106: Line 106:
 Ab hier läuft dann die Pipeline ganz normal weiter. Ab hier läuft dann die Pipeline ganz normal weiter.
  
-=== Variante 2: eigenes Masterfile+### Variante 2: eigenes Masterfile
  
 Alternativ kann ein Master-File separat erzeugt und eingeschleust werden, hierbei sind jedoch wesentlich mehr Rahmenbedingungen zu beachten: Alternativ kann ein Master-File separat erzeugt und eingeschleust werden, hierbei sind jedoch wesentlich mehr Rahmenbedingungen zu beachten:
  • events/cccamp15/pp.1524497287.txt.gz
  • Last modified: 2018/04/23 15:28
  • by derpeter