events:cccamp15:pp

CCCamp15 Recording / Postprocessing

Kurzer Abriss der Pipeline, streng chronologisch:

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

“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

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

$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: <EMPTY>
root@tarantel:/home/atze# mount.cifs //10.73.0.2/fuse   /video/fuse -ouid=atze
Password: <EMPTY>

Schnitt erfolgt mit KDEnlive. Tools: kdenlive, Webbrowser, Tracker

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!

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!

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: <EMPTY>
mount /video/cccamp15/tmp/
Password:  <EMPTY>
mount /video/cccamp15/encoded/
Password:  <EMPTY>

Im Tracker ist ein Filter an der Worker Group eingerichtet, so dass die Encoder in Mildenberg nur die Master-Encoding-Tickets erhalten. Tools: ffmpeg

Analog Schnitt

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 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.

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.

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.

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.

Komplett identisch zu Master-Files

Es gibt zwei Stellen, an denen reparierte Aufzeichnungen halbwegs elegant in die Pipeline eingeschleust werden können:

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.

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.

  • events/cccamp15/pp.txt
  • Last modified: 2018/04/23 17:28
  • by derpeter