Vorträge%2FRecording-Workflow.mw

   1 Am Anfang – Januar 2012, zwei Wochen nach Einzug in [[Space 1.0]] – war ein grütziger Beamer (Epson EMP3000, "Die Kanone", 640x480), ein DV-Camcorder und ein {{Benutzer|Daniel Bohrer}} der sich drum gekümmert hat, dass wir auch heute noch auf Aufzeichnungen zurückblicken können von einem Haufen an Entitäten, die ihr Wissen teilen wollten.
   2
   3 Später – ab 2014 und zum Anfang des [[Space 2.0]] – kam dann {{Benutzer|Sintox}} dazu und hat zum Einen durch ein [[Crowdfunding]] für besseres Audio-Aufnahme-Equipment gesorgt, andererseits auch einen Workflow für OBS eingeführt. Dies hat zu einer wesentlichen Verbesserung bei Audio- und Bildqualität geführt, brachte aber als neues Problem mit, dass der Präsentationsrechner auch aufzeichnen musste.
   4 Bei uns zeigen jedoch häufig auch Entitäten Dinge von ihren eigenen Endgeräten, die Benutzung eines Präsentationsrechners skalierte nicht lang.
   5
   6 Im Sommer 2015 gab es auf dem Chaos Communication Camp einen Workshop zu Vortragsaufzeichnung in Hackerspaces, wo wir uns mit anderen Spaces kurzgeschlossen haben. Unmittelbar ist daraus zwar nichts hervorgegangen, aber mittelfristig darauf aufbauend haben wir versucht, ein wenig beim VOC abzugucken.
   7
   8 Seit einigen Jahren werden die Aufzeichnungen größtenteils von {{Benutzer|larsan}} durchgeführt.
   9
  10 Der aktuelle Standardworkflow wird auf dieser Seite beschrieben, dazu Verworfenes erwähnt, Probleme aufgeführt und Pläne für die Zukunft vorgestellt.
  11
  12 == Aktueller Workflow ==
  13 An einem Vortragsabend wird zunächst der Chillraum ein Speakersessel neben der Leinwand positioniert und die [[Spacekiste]] ins Debian gebooted.
  14 === Aufnahme ===
  15 ==== Audio ====
  16 * In Speakernähe wird ein Laptop ([[Herbert]]) mit einem der Samson Meteor Mikrofone (auf Schaumstoff aufgestellt) aufgebaut, die Aufnahme erfolgt in Audacity.
  17 ==== Screencapture ====
  18 * Vom Speakerendgerät geht ein HDMI-Kabel zunächst zu einem HDMI-Splitter, von dort zum Einen via HDMI zum Verstärker und weiter zum Beamer, zum Anderen in den HDMI-Input einer [https://c3voc.de/wiki/hardware:android-hdmi-in Android-TV-Box]
  19 * Die Android-TV-Box macht effektiv nichts anderes als das HDMI-Signal durchzuschleifen, hat aber den Vorteil, dass sie durchgehend ein definiertes HDMI-Signal am Output erzeugt, auch wenn der Speakerlaptop gerade abgezogen wurde. Zudem fungiert sie als Scaler mit niedriger Latenz.
  20 * Das Outputsignal von der Android-TV-Box geht dann via HDMI-Kabel in eine Blackmagic DeckLink Mini Recorder PCIe-Karte in der Spacekiste.
  21 * Auf der Spacekiste liegt ein ffmpeg in das Support für die DeckLink-Karte mit einkompiliert wurde.
  22 * Theoretisch kann hiermit direkt der Input weggeschrieben werden. Aus historischen Gründen nimmt das Signal aber derzeit noch einen Extraweg über einen nginx mit rtmp-plugin (ebenfalls auf der Spacekiste, startet automatisch) und wird erst danach weggespeichert, dafür kann das wegspeichern überall im Netzwerk passieren.
  23 ** rtmp-Statusseite: http://192.168.178.185:8080/stat
  24 ** ffmpeg-Einzeiler auf der Spacekiste um den Decklink-Input wegzustreamen:
  25 ***<code>ffmpeg_voc -v verbose -f decklink -i 'DeckLink Mini Recorder' -an -c:v libx264 -pix_fmt yuv420p -preset veryfast -crf 25 -f flv rtmp://192.168.178.185:1935/stream/input</code>
  26 ** ffmpeg-Einzeiler auf beliebiger Maschine im Spacenetz um den rtmp-Stream wegzuspeichern:
  27 ***<code>ffmpeg -i rtmp://192.168.178.185:1935/stream/input -acodec copy -vcodec copy ~/file.mkv</code>
  28 * Ebenso kann der Stream zur Kontrolle mit beliebigen Videoplayern direkt angezeigt werden, z.B. vlc: <code><rtmp://192.168.178.185:1935/stream/input</code>
  29 ==== Kameras ====
  30 * Eine Speakercam haben wir derzeit noch nicht, das liegt an mehreren Gründen, zum Einen saßen die Vortragenden früher meist mit im Publikum, das hat sich erst in jüngster Zeit zu einem Speakersessel neben der Leinwand, dem Großteil des Publikums gegenübersitzend, geändert, zum Anderen fehlt eine ausreichend lichtstarke Kamera. Dazu kommt der Aufwand, das nachzubearbeiten/reinzuschneiden. Im Ideallfall würde während des Vortrags schon fertig gemischt werden.
  31 * Als Detailkamera (z.B. zum Zeigen von Hardware) haben wir bisher verschiedene Lösungen gehabt, entweder einen Panasonic HC-V520 Camcoder, oder Androidtelefone mit rtmp-streaming Apps (Streamlabs, RTMP Camera, BitStream,…), relevante Szenen werden dann im Nachhinein mit ins Video geschnitten. Beispiel: [https://www.youtube.com/watch?v=A8wLBhL5Bw0&t=1208 Drahflows 3D-Display]
  32 * Eine Raumkamera hatten wir kurzfristig, derzeit nicht mehr. Hat bei A/V-Sync unterstützt, ist aber aufgrund der beengten Verhältnisse nicht für ein Streamingsetup geeignet, man würde ständig Entitäten sehen.
  33
  34 === Nachbearbeitung ===
  35 ==== Audio ====
  36 In Audacity wird die Audioaufzeichnung nachbearbeitet, in drei Schritten:
  37 * Störgeräusche
  38 ** Dazu die Anzeige der Aufnahme auf "Spectrogram" stellen (im Dropdown über "Mute" und "Solo") und danach im gleich Dropdown bei den Spectrogram Settings die "Window Size" auf "32768 most narrowband" stellen.
  39 ** Aus bisher noch unbekannten Gründen, gibt es bei einigen Aufnahmen ein Störsignal bei jedem Vielfachen von 1000Hz, diese können leicht mit einem Nyquist-Befehl schmalbandig rausgeschnitten werden
  40 *** <code>(notch2 (notch2 (notch2 (notch2 (notch2 (notch2 s 6000 800) 5000 400) 4000 200) 3000 100) 2000 60) 1000 30)</code>
  41 * Rauschen
  42 ** eine stille Stelle markieren, "Effect->Noise reduction->Get Noise Profile" auswählen, dann die ganze Aufnahme markieren, "Effect->Noise reduction->OK", meist nehme ich 4-6 dB bei 4-6 Sensitivity, manchmal zwei Durchläufe an mit verschiedenen Noise Profiles.
  43 * Kompressor
  44 ** Es empfiehlt sich, die Aufnahme einmal durch einen Kompressor zu jagen, das schränkt zwar den Dynamikumfang ein, aber nicht alle, die sich die Aufnahme ansehen, werden dies in einer ruhigen Umgebung tun und so werden z.B. auch die Nachfragen aus dem Publikum hörbar.
  45 ** rohieb hatte im alten Setup folgende Settings für den Kompressor genutzt:
  46     Threshold: -34 dB
  47     Noise Floor: -40 dB
  48     Ratio: 10:1
  49     Attack Time: 0.1 s
  50     Release Time: 1 s
  51 In ffmpeg-Syntax ist das: <code>-af 'compand=attacks=0:points=-80/-80|-35/-3.5|0/-1'</code>
  52
  53 ==== Video ====
  54 * In früheren Aufzeichnungssetups hatten wir noch Probleme mit abreißenden Aufzeichnungen, wenn Speaker das Kabel aus ihrem Laptop zogen, entsprechend kaputte Videos konnten meist dadurch repariert werden, indem sie einmal durch ffmpeg geschoben wurden
  55 ** <code>ffmpeg -i input.mkv -acodec copy -vcodec copy output.mkv</code>
  56 * Manchmal wird vergessen, redshift auszuschalten. Wenn es sich dabei um statisches Redshift handelt, das nicht über die Vortragsdauer shifted, lässt sich das im nächsten Schritt, während des Schnitts z.B. mittels einer 3-Punkt-Balance korrigieren
  57 ==== Titlescreens ====
  58 * Die Anfangs- und Endfolie werden aus den im Wiki angegebenen Titeln erzeugt. Rohieb hat da [https://gitli.stratum0.org/stratum0/talk-recordings ein Script] für geschrieben.
  59 * Manche Titel müssen manuell nachbearbeitet werden, z.B. weil sie zu lang sind, oder weil Sonderzeichen eingefügt werden sollen, die das Script nicht überträgt. Hierfür empfiehlt sich Inkscape. .svg-Features, die von Inkscape nicht in der GUI abgebildet werden (z.B. durchgestrichener Text), können im XML-Editor eingefügt werden, Inkscape rendert sie meist korrekt.
  60 * Da nicht alle Schnittprogramme .svgs besonders gut rendern, werden sie noch kurz zu .png exportiert:
  61 ** <code>for i in *.svg; do inkscape -z -e $i.png $i; done</code>
  62
  63 === Schnitt ===
  64 * Derzeit ausschließlich in Kdenlive
  65 ** Kdenlive Voreinstellungen: 1080p30, Clip-Länge: 4s
  66 * Zunächst werden alle Dateien in ein Projekt geworfen, die Audio- und Videospuren werden hier miteinander synchronisiert.
  67 * Danach wird für jeden Vortrag des Vortragsabends die Projektdatei kopiert und dann je Projekt:
  68 ** alles rausgeschmissen, was nicht mehr benötigt wird
  69 ** Audio und Video auf Vortragsanfangszeitpunkt und Endzeitpunkt (meist nach Applaus) getrimmt
  70 ** fade-in und fade-out fürs Audio eingefügt
  71 ** Titlescreens eingefügt (Endscreen halb überlappend mit Videoende)
  72 ** Bei Bedarf Kamerabild an benötigten Stellen reingeschnitten
  73
  74 === Rendering ===
  75 * MP4(H264/AAC)
  76
  77 === Veröffentlichung ===
  78 * Die fertigen Aufzeichnungen werden dann als unlisted auf den [https://www.youtube.com/stratum0/ Stratum 0 Youtube-Channel] hochgeladen, darauf haben {{Benutzer|Daniel Bohrer}} und {{Benutzer|larsan}} Zugriff.
  79 * Der Link wird zur Endkontrolle den Vortragenden geschickt. Falls es doch nicht veröffentlicht werden soll, oder falls z.B. noch Dinge überblendet werden sollen.
  80 ==== Freischalten ====
  81 Wenn alles okay ist wird das Video im Idealfall
  82 * public geschaltet
  83 * in entsprechende [https://www.youtube.com/user/stratum0/playlists Playlists] einsortiert
  84 * im irc verlinkt
  85 * vertwittert/getootet
  86 * in [[Vorträge/Vorbei]] verlinkt
  87 * in den [[Stratumnews]] verlinkt.
  88
  89 == Ausprobiert/Verworfen ==
  90 === Voctomix ===
  91 Beim Versuch, sich einiges beim VOC abzugucken, haben wir natürlich auch [https://github.com/voc/voctomix voctomix] ausprobiert. Es trifft aber einfach nicht unseren usecase:
  92 * Für mehrtägige Veranstaltungen lohnt es sich in das Setup und die Konfiguration Zeit und Aufwand zu stecken, um es sauber aufzubauen, bei unseren kurzen Vorträgen einmal im Monat ist die Wahrscheinlichkeit hoch, dass irgendwer seit den letzten Vorträgen ein HDMI-Kabel umgesteckt hat, etc.
  93 * Es passiert häufig, dass bei uns Dinge direkt in der shell gezeigt werden und da man bei uns, im Gegensatz zu den meisten Congressvorträgen, auch das Tippen hören kann und nicht nur was die Speaker gerade sagen, haben wir viel höhere Anforderungen an A/V-Sync als z.B. das VOC für Congresstalks. Zuviel A/V-Desync ist einfach unangenehm zu schauen/hören. Und nahezu perfekter A/V-Sync lässt sich derzeit nur durch ein sehr gut darauf optimiertes System, oder eben durch manuelle Synchronisation der Inputs in der Nachbearbeitung erreichen.
  94 === Audioaufzeichnungspi ===
  95 Eine Zeit lang wurde auf einem BananaPi mit einem der USB-Mikrofone Audio aufgezeichnet. Idee war, ein portables (bei Bedarf auch akkubetriebenes) Setup zu haben, das neben lokaler Aufzeichnung das Audio auch über WLAN wegstreamt, damit es irgendwo anders, z.B. in einem OBS direkt mit reingemischt werden konnte. Hat sich aber nicht durchgesetzt, bzw. nie so richtig funktioniert und der zusätzliche Aufbauaufwand war es einfach nicht wert.
  96 === Raumkamera ===
  97 Permanent verkabelte Kameras in einen Hackerspace zu hängen funktioniert einfach nicht. Aus guten Gründen. D.h. man müsste sie jedes Mal wieder aufbauen/ausrichten/anstöpseln etc. Dafür war der Nutzen bisher einfach nicht groß genug.
  98 Eine Idee war, unter Annahme von Livestreamingbedingungen, das Kamerabild mit entsprechenden Filtern zu verblurren, sodass zwischen Vorträgen der Stream darauf schalten kann und Zuschauer sehen, dass sich gerade was tut (Leute Plätze wechseln etc.) aber keine Entitäten unfreiwillig live ins Internet gestreamt werden.
  99
 100
 101 == Probleme/Limitierungen ==
 102 === HDCP ===
 103 Manche Endgeräte wollen mehr Crypto, als für sie gut ist (subjektiv betrachtet meist Apple-Geräte). Der noname HDMI-Splitter hilft da meist schon ganz gut, aber es kommt immer noch mal wieder ein Laptop, mit dem es Probleme gibt. Stabil ist das Setup nicht. Aber selbst das VOC greift wohl in Extremfällen auf eine Digital->Analog->Digital-Kette zurück, wenn sonst nichts hilft.
 104 === Audio ===
 105 * Wir nehmen derzeit nicht direkt die Speaker, sonder mehr den Raum, aber recht nah am Speaker auf. Hat den Vorteil, dass wir die Speaker nicht verkabeln müssen und Publikumsfragen in der Aufzeichnung direkt verständlich sind, andererseits wird auch alles andere aus dem Publikum mit aufgezeichnet.
 106 * Speaker Sessel-Mikros und Live Audio Mischen könnte die Situation verbessern
 107 === Video ===
 108 * Manche Geräte geben komische Formate aus. z.B. lieber 1080i60 statt 1080p30. Das muss rechtzeitig bemerkt und behoben werden.
 109 * Redshift fällt während eines Vortrags meist nicht auf, aber extrem beim Anschauen einer Aufzeichnung.
 110 * Kaputte Aufzeichnung
 111 ** Wenn die Videoaufzeichnung hoffnungslos kaputt ist (aber Audio vorhanden) kann sie mit einiges an manuellem Aufwand halbwegs gerettet werden, sofern der Vortrag mit Folien gehalten wurde, und zwar indem die Folien manuell eingefügt werden. Wurde schon bei 1-2 Vorträgen gemacht. Eine Raumkamera hilft hier natürlich ungemein.
 112 === Laserpointer ===
 113 ** Wenn zum Zeigen auf einer Slide nicht die Maus, sondern ein Laserpointer genutzt wird, landet davon nichts in der Aufzeichnung, ein Informationskanal fehlt.
 114 ** Es gibt OpenCV-Projekte zum Tracken von Laserpointern, Implementierungsversuche wurden bisher nicht unternommen, zudem edge-case.
 115
 116 == Pläne/Optionen/Wünsche ==
 117 === Speakercam ===
 118 Auch für analoge Vorträge wichtig. Sollte auch bei nichtoptimalen Lichtbedingungen ein gutes Bild liefern.
 119 === Detailcam ===
 120 Irgendwas, hauptsache besser als was wir akutell haben. Z.B. ein moderneres Android-Endgerät, oder eine Actioncam mit 1080p-Output.
 121 === Mikrofone ===
 122 * Funk-Lavaliermikrofone
 123 * Raummikrofone
 124 === Livestreaming/OBS ===
 125 Um irgendwann unsere Vorträge live streamen zu können, brauchen wir mindestens eine Lösung, bei der alle Medien halbwegs synchron live gemischt werden.
 126
 127
 128 == Vorhandene Hardware ==
 129 * [[Beamer]]: Sony VPL PHZ10
 130 * A/V-Receiver Onyko TY-NR636
 131 ** 2*HDMI-OUT(main+sub), x*HDMI-IN
 132 ** [http://www.de.onkyo.com/assets/2/6/5/9/2/TX-NR636__B__Rear_N4049x2207.jpg Anschlüsse hinten]
 133 * [[Spacekiste]] als Aufzeichnungsrecher
 134 * Zidoo X8 Android TV Box
 135 ** HDMI-IN + HDMI-OUT
 136 ** USB3, GBit Eth, 32GB µSD
 137 ** rooted
 138 * Audio
 139 ** Rode Videomic (Klinke)
 140 ** 2* Samson Meteor Mic (USB)
 141 * Kamera
 142 ** Panasonic V520
 143 *** zeichnet 1080p50? auf
 144 *** Mini-HDMI-Out (nur 720p)
 145 *** Kann prinzipiell über WLAN streamen
 146 * noname HDMI-Splitter
 147 * Stative
 148 ** Mikrofonständer: K&M 210/2
 149 ** Kamerastativ: Manfrotto 190XProB mit 496RC2 Kugelkopf
 150 ** 2 Ministative
 151
 152 == History ==
 153 * 2020 wurde der alte Inhalt dieser Seite nach [[Vorträge/Recording-Workflow/alt2020]] verschhoben.