Differences

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

--- cccamp15:pp [2015/08/13 13:52] – [Schnitt] atze
+++ events:cccamp15:pp [2016/03/22 10:40] – ↷ Page moved from cccamp15:pp to events:cccamp15:pp v0tti
@@ Line 1: / Line 1: @@
+= CCCamp15 Recording / Postprocessing
+Kurzer Abriss der Pipeline, streng chronologisch:
+== 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)
+Segmentierte Aufnahmen landen in <code>/video/{{ room_fahrplan_name | lower | replace(' ', '') }}-%t-%05d.ts</code>
+== 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**
+== 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.
+Um die "read only" Option von Samba nutzen zu können, werden ''/video'', ''/video/fuse'' und die Verzeichnisse ''tmp'' und ''encoded'' als separater Share angeboten. Dabei ist ''/video'' R/O, während ''fuse'', ''tmp'' und ''encoded'' beschreibbar sind.
+Tools: **screen**, **fuse-ts**, **samba**
+== Schnitt
+$Mensch mountet per CIFS vom VOC-Storage das /video an:
+<code>
+root@tarantel:/home/atze# mount.cifs //10.73.0.2/video/ /video/ -ouid=atze
+Password: <EMPTY>
+root@tarantel:/home/atze# mount.cifs //10.73.0.2/fuse   /video/fuse -ouid=atze
+Password: <EMPTY>
+</code>
+Schnitt erfolgt mit KDEnlive. Tools: **kdenlive**, **Webbrowser**, **Tracker**
+<note warning>Vor der Benutzung von "Timeline is too short" oder einem manuellen Statuswechsel zurück auf ''recorded'' muss unbedingt das KDEnlive Project geschlossen werden, da es die Files lockt und das ''umount'' verhindert!</note>
+<note 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!**</note>
+== 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.
+Ausschnitt ''/etc/fstab'':
+<code>
+//10.73.0.2/video   /video		cifs	ro,user,noauto
+#//10.73.0.2/fuse    /video/fuse	cifs	ro,user,noauto
+//10.73.0.2/tmp     /video/cccamp15/tmp		cifs	rw,user,noauto
+//10.73.0.2/encoded /video/cccamp15/encoded	cifs	rw,user,noauto
+</code>
+Anlegen der CIFS-Mounts nach Boot:
+<code>
+mount /video/
+Password: <EMPTY>
+mount /video/cccamp15/tmp/
+Password:  <EMPTY>
+mount /video/cccamp15/encoded/
+Password:  <EMPTY>
+</code>
+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
+Analog Schnitt
+== 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**
+== 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.
+== 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.
+== 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.
+FIXME Eine Einschränkung auf IP-Bereiche und/oder Basic Auth ist evtl. sinnvoll.
+== 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.
+== Releasing Slave-Files
+Komplett identisch zu Master-Files
+== Reparaturprozess, allgemein
+Es gibt zwei Stellen, an denen reparierte Aufzeichnungen halbwegs elegant in die Pipeline eingeschleust werden können:
+=== 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.
+Die Vorgehensweise wird vom Tracker etwas unterstützt (FIXME ist das noch/wieder so? Prüfen, Screenshot). Das Material ist als ein zusammenhängendes TS-File im Verzeichnis ''Processing.Path.Repair'' abzulegen. Dabei kann ein beliebiger Dateiname gewählt werden. Im Tracker muss dieser Dateiname dann in die Property ''Record.SourceReplacement'' am zugehörigen Recording-Ticket eingetragen werden. Das Recording-Ticket ist anschließend auf den Status ''recorded'' zu setzen. Das Mount-Skript erkennt den Sonderfall der Reparatur, und statt eines Fuse-Mounts wird einfach ein Softlink gesetzt. **Achtung** hier ist zu beachten, dass die Encoder das Ziel des Softlinks ebenfalls erreichen können! Daher am Besten alles unter einem Verzeichnis, z.B. ''/video'' bereitstellen.
+Direkt im Anschluss kann/muss das Ticket nochmal geschnitten werden, also den Cutting-Status durchlaufen. Es wird **nur** der Status im Tracker durchlaufen, ein Schnitt mit KDEnlive findet **nicht** statt. Hier wäre jetzt der richtige Moment, um z.B. falsch gesetzte Sprachen/Übersetzungen nochmal zu korrigieren.
+Ab hier läuft dann die Pipeline ganz normal weiter.
+=== Variante 2: eigenes Masterfile
+Alternativ kann ein Master-File separat erzeugt und eingeschleust werden, hierbei sind jedoch wesentlich mehr Rahmenbedingungen zu beachten:
+  * das File sollte mit identischen Parametern zu den automatisiert erzeugten Files encodet sein
+  * das File muss auch alle Metadaten beinhalten
+  * ''Record.Language'' muss korrekt gesetzt sein
+Es empfiehlt sich, aus dem Encodingprofil den ffmpeg-Befehl herauszufiltern und zu verwenden. Dazu sollte die "Download Jobfile" Funktion am Master-Ticket verwendet werden. Darüber kann man das fertige XML-Jobfile erhalten, welches z.B. alle Metadaten enthält.
+Das fertige Masterfile muss mit dem richtigen Namen ''$id-$slug.mp4'', also z.B. ''1234-hd.mp4'' im Verzeichnis ''Processing.Path.Output'' hinterlegt werden. Anschließend ist folgende Ticket-Konstellation (in dieser Arbeitsreihenfolge!) einzustellen:
+  * Slave-Encoding-Tickets: material needed
+  * Master-Encoding-Ticket: postencoded oder checked, je nachdem ob nochmal jemand anderes drüberschauen soll
+  * Recording-Ticket: finalized
+  * Slave-Encoding-Tickets: ready to encode (falls Recording schon auf finalized stand)
+Ab hier arbeitet die Pipeline normal weiter.