X-Git-Url: http://git.rohieb.name/stratum0-wiki.git/blobdiff_plain/9aca3c91b29da1a8ee904fa7c38dd59851b9ff67..01b3e3fb609ab41e17d51d0899f2d8b590f1980a:/Vortr%C3%A4ge%2FRecording-Workflow.mw?ds=sidebyside diff --git "a/Vortr\303\244ge%2FRecording-Workflow.mw" "b/Vortr\303\244ge%2FRecording-Workflow.mw" index 1703e3b92..c83293a72 100644 --- "a/Vortr\303\244ge%2FRecording-Workflow.mw" +++ "b/Vortr\303\244ge%2FRecording-Workflow.mw" @@ -1,20 +1,153 @@ -Es folgen einige Notizen zum Workflow, den ich ([[Benutzer:Daniel Bohrer|Daniel Bohrer]]) zum Nachbearbeiten von Vortragsmitschnitten verwende. +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. -== Schneiden == -Zum Schneiden der Videos verwende ich [http://www.avidemux.org/admWiki/doku.php Avidemux]. Einfach mit den A- und B-Markern den gewünschten Bereich auswählen und unter einem neuen Namen speichern. Das ganze funktioniert auch ohne Recodieren, wenn man die Marker nur an Keyframes platziert (mit den Doppelpfeil-Buttons auf der Toolbar) und als Video- und Audiocodec „Copy“ auswählt. +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. +Bei uns zeigen jedoch häufig auch Entitäten Dinge von ihren eigenen Endgeräten, die Benutzung eines Präsentationsrechners skalierte nicht lang. -Avidemux hat im Moment noch Probleme mit Dateien, die B-Frames enthalten. Wenn es beim Laden der Datei fragt, wähle ich den frame-genauen Modus, um präzise schneiden zu können. +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. -== Nachbearbeitung == -Nachdem Schneiden füge ich mit [http://openshot.org/download/ OpenShot] noch Title und End Screens hinzu. Vorlagen dafür: -* [[Datei:Recording Title Screen.svg]] -* [[Datei:Recording End Screen.svg]] -Die SVGs kann man einfach zum Projekt hinzufügen und dann relativ bequem über das Kontextmenü („Edit (simple)“ bzw „Edit (Inkscape)“) bearbeiten. Nachdem man die Platzhalter in den Vorlagen ersetzt hat, kann man die Screens auf die Timeline ziehen. +Seit einigen Jahren werden die Aufzeichnungen größtenteils von {{Benutzer|larsan}} durchgeführt. -Zusätzlich füge ich Überblendungen zwischen dem Title Screen und dem Vortrag sowie dem Vortrag und dem End Screen hinzu (Rechtsklick auf die entsprechenden Abschnitte in der Timeline, im Untermenü „Fade“). +Der aktuelle Standardworkflow wird auf dieser Seite beschrieben, dazu Verworfenes erwähnt, Probleme aufgeführt und Pläne für die Zukunft vorgestellt. -Danach wird das ganze exportiert („File“ → „Export Video“, Profile: „Web“, Target: „YouTube-HD“, Video Profile: „HD 720p 25 fps“, Quality: „High“). +== Aktueller Workflow == +An einem Vortragsabend wird zunächst der Chillraum ein Speakersessel neben der Leinwand positioniert und die [[Spacekiste]] ins Debian gebooted. +=== Aufnahme === +==== Audio ==== +* In Speakernähe wird ein Laptop ([[Herbert]]) mit einem der Samson Meteor Mikrofone (auf Schaumstoff aufgestellt) aufgebaut, die Aufnahme erfolgt in Audacity. +==== Screencapture ==== +* 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] +* 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. +* Das Outputsignal von der Android-TV-Box geht dann via HDMI-Kabel in eine Blackmagic DeckLink Mini Recorder PCIe-Karte in der Spacekiste. +* Auf der Spacekiste liegt ein ffmpeg in das Support für die DeckLink-Karte mit einkompiliert wurde. +* 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. +** rtmp-Statusseite: http://192.168.178.185:8080/stat +** ffmpeg-Einzeiler auf der Spacekiste um den Decklink-Input wegzustreamen: +***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 +** ffmpeg-Einzeiler auf beliebiger Maschine im Spacenetz um den rtmp-Stream wegzuspeichern: +***ffmpeg -i rtmp://192.168.178.185:1935/stream/input -acodec copy -vcodec copy ~/file.mkv +* Ebenso kann der Stream zur Kontrolle mit beliebigen Videoplayern direkt angezeigt werden, z.B. vlc: +==== Kameras ==== +* 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. +* 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] +* 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. -Die Recodierung auf eine möglichst kleine Dateigröße lasse ich dann einfach YouTube machen… :P +=== Nachbearbeitung === +==== Audio ==== +In Audacity wird die Audioaufzeichnung nachbearbeitet, in drei Schritten: +* Störgeräusche +** 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. +** 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 +*** (notch2 (notch2 (notch2 (notch2 (notch2 (notch2 s 6000 800) 5000 400) 4000 200) 3000 100) 2000 60) 1000 30) +* Rauschen +** 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. +* Kompressor +** 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. +** rohieb hatte im alten Setup folgende Settings für den Kompressor genutzt: + Threshold: -34 dB + Noise Floor: -40 dB + Ratio: 10:1 + Attack Time: 0.1 s + Release Time: 1 s +In ffmpeg-Syntax ist das: -af 'compand=attacks=0:points=-80/-80|-35/-3.5|0/-1' -[[Kategorie:Dokumentation]] +==== Video ==== +* 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 +** ffmpeg -i input.mkv -acodec copy -vcodec copy output.mkv +* 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 +==== Titlescreens ==== +* 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. +* 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. +* Da nicht alle Schnittprogramme .svgs besonders gut rendern, werden sie noch kurz zu .png exportiert: +** for i in *.svg; do inkscape -z -e $i.png $i; done + +=== Schnitt === +* Derzeit ausschließlich in Kdenlive +** Kdenlive Voreinstellungen: 1080p30, Clip-Länge: 4s +* Zunächst werden alle Dateien in ein Projekt geworfen, die Audio- und Videospuren werden hier miteinander synchronisiert. +* Danach wird für jeden Vortrag des Vortragsabends die Projektdatei kopiert und dann je Projekt: +** alles rausgeschmissen, was nicht mehr benötigt wird +** Audio und Video auf Vortragsanfangszeitpunkt und Endzeitpunkt (meist nach Applaus) getrimmt +** fade-in und fade-out fürs Audio eingefügt +** Titlescreens eingefügt (Endscreen halb überlappend mit Videoende) +** Bei Bedarf Kamerabild an benötigten Stellen reingeschnitten + +=== Rendering === +* MP4(H264/AAC) + +=== Veröffentlichung === +* 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. +* 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. +==== Freischalten ==== +Wenn alles okay ist wird das Video im Idealfall +* public geschaltet +* in entsprechende [https://www.youtube.com/user/stratum0/playlists Playlists] einsortiert +* im irc verlinkt +* vertwittert/getootet +* in [[Vorträge/Vorbei]] verlinkt +* in den [[Stratumnews]] verlinkt. + +== Ausprobiert/Verworfen == +=== Voctomix === +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: +* 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. +* 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. +=== Audioaufzeichnungspi === +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. +=== Raumkamera === +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. +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. + + +== Probleme/Limitierungen == +=== HDCP === +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. +=== Audio === +* 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. +* Speaker Sessel-Mikros und Live Audio Mischen könnte die Situation verbessern +=== Video === +* Manche Geräte geben komische Formate aus. z.B. lieber 1080i60 statt 1080p30. Das muss rechtzeitig bemerkt und behoben werden. +* Redshift fällt während eines Vortrags meist nicht auf, aber extrem beim Anschauen einer Aufzeichnung. +* Kaputte Aufzeichnung +** 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. +=== Laserpointer === +** Wenn zum Zeigen auf einer Slide nicht die Maus, sondern ein Laserpointer genutzt wird, landet davon nichts in der Aufzeichnung, ein Informationskanal fehlt. +** Es gibt OpenCV-Projekte zum Tracken von Laserpointern, Implementierungsversuche wurden bisher nicht unternommen, zudem edge-case. + +== Pläne/Optionen/Wünsche == +=== Speakercam === +Auch für analoge Vorträge wichtig. Sollte auch bei nichtoptimalen Lichtbedingungen ein gutes Bild liefern. +=== Detailcam === +Irgendwas, hauptsache besser als was wir akutell haben. Z.B. ein moderneres Android-Endgerät, oder eine Actioncam mit 1080p-Output. +=== Mikrofone === +* Funk-Lavaliermikrofone +* Raummikrofone +=== Livestreaming/OBS === +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. + + +== Vorhandene Hardware == +* [[Beamer]]: Sony VPL PHZ10 +* A/V-Receiver Onyko TY-NR636 +** 2*HDMI-OUT(main+sub), x*HDMI-IN +** [http://www.de.onkyo.com/assets/2/6/5/9/2/TX-NR636__B__Rear_N4049x2207.jpg Anschlüsse hinten] +* [[Spacekiste]] als Aufzeichnungsrecher +* Zidoo X8 Android TV Box +** HDMI-IN + HDMI-OUT +** USB3, GBit Eth, 32GB µSD +** rooted +* Audio +** Rode Videomic (Klinke) +** 2* Samson Meteor Mic (USB) +* Kamera +** Panasonic V520 +*** zeichnet 1080p50? auf +*** Mini-HDMI-Out (nur 720p) +*** Kann prinzipiell über WLAN streamen +* noname HDMI-Splitter +* Stative +** Mikrofonständer: K&M 210/2 +** Kamerastativ: Manfrotto 190XProB mit 496RC2 Kugelkopf +** 2 Ministative + +== History == +* 2020 wurde der alte Inhalt dieser Seite nach [[Vorträge/Recording-Workflow/alt2020]] verschhoben.