= 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 /video/{{ room_fahrplan_name | lower | replace(' ', '') }}-%t-%05d.ts == 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: root@tarantel:/home/atze# mount.cifs //10.73.0.2/video/ /video/ -ouid=atze Password: root@tarantel:/home/atze# mount.cifs //10.73.0.2/fuse /video/fuse -ouid=atze Password: Schnitt erfolgt mit KDEnlive. Tools: **kdenlive**, **Webbrowser**, **Tracker** 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! 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!** == 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'': //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 Anlegen der CIFS-Mounts nach Boot: mount /video/ Password: mount /video/cccamp15/tmp/ Password: mount /video/cccamp15/encoded/ Password: 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.