Problem: Ich recorde meinen Bildschirm mit OBS. Aber irgendwie sieht alles bereits im Video-Editor viel schlechter aus als noch live auf dem Bildschirm. (Im Beispiel und Screenshot: ProjectM Music Visualizer)
Lösung: Ich schalte möglichst alle Umwandlungen ab, d.h. ich konfiguriere OBS auf die Auflösung meines Bildschirms, auf die Bildwiederholrate meines Bildschirms, auf keine Farbunterabtastung (Chroma-Subsampling) und wähle obendrein eine exorbitant hohe Bitrate beim Video-Encoding.
Nun zum Hintergrundwissen:
Im digitalen Video gibt es diverse Bildqualitätskiller: Am bekanntesten dürfte eine niedrige Bitrate bei Video-Codecs wie h264 oder h265 (für viele Synonym mit: MP4-Video) sein. Das Bild wird grob, Block-Artefakte und Color-Banding sind zu sehen. Weniger bekannt ist das Chroma-Subsampling, was fährlässig vereinfachend ausgedrückt bedeutet, dass nicht alle Farben die gleiche Auflösung bekommen – das fällt besonders auf bei Screen-Recording, weniger in natürlichen Bildern von Kameras – so wird zum Beispiel eine leuchtend rote Schrift in der Videodatei auf einmal unscharf, die vorher im Video-Editor noch scharf war. Ein ziemlicher Killer ist auch eine schlechte Konvertierung der Bildwiederholrate, insbesondere von 60 auf 50 Bildern pro Sekunde, oder von 30 auf 25 – und jeweils umgekehrt. Von 60 auf 30 sowie 50 auf 25 und umgekehrt ist es nicht weiter tragisch, hier kann jedes zweite Bild genommen oder ein Bild jeweils verdoppelt werden. Das Errechnen von Zwischenbildern jedoch führt meistens zu Gruseligkeit. Ein den meisten Leuten völlig unbekannter Killer ist das lausige Detail, dass ursprünglich im Fernsehen nicht die volle Dynamik des Signals genutzt werden konnte, weswegen Dateiformate wie ProRes nicht die Helligkeitswerte 0-1023 (10bit) verwenden, sondern nur ca. 85% davon, nämlich nur die Werte 64-940 – viele Videosoftware, inklusive YouTube, bläst den reduzierten Dynamikbereich aber nicht automatisch wieder voll auf, und beim Konvertieren auf die an den Betrachter ausgelieferten 0-255 (8bit) reduziert sich die Dynamikauflösung dann in spürbar grobe Abstufungen.
Was kann man nun also beim Screen-Recording in OBS tun?
Zunächst mal: In den erweiterten Optionen das Farbformat auf i444 8bit 4:4:4 umstellen – das steht für volle Auflösung für alle 3 Farbkanäle, also eben kein Chroma-Subsampling – und ebendort den Farbbereich (Dynamikbereich) von Begrenzt auf Voll stellen – die meisten Leute verwenden nur 8bit Dynamikauflösung auf dem Bildschirm, das passt dann damit:
Unter Video dann die Auflösungen und die Bildwiederholrate genau so einstellen, wie der Bildschirm eingestellt ist, bei FullHD sind das meistens 60Hz/FPS und eben 1920×1080. Sollte die Bildwiederholrate in einem Film dann doch 50 oder oder 25 FPS sein müssen, so ist zu hoffen, dass mein Video-Editor beim Export des geschnittenen Films nur die allerfeinsten Konvertierungs-Algorithmen darauf anwendet.
Dann in den Einstellungen für die Aufnahme eine lächerlich hohe Bitrate wählen (z.B. hier 150mbps) – je höher die Bitrate, desto irrelevanter ist die spezifische Encoder-Implementierung für die Videoqualität. Hier kann auch die in der Regel schlechtere Implementierung des GPU-Encoders genutzt werden anstatt libx264 auf der CPU. Allerdings klappt das hier nur, wenn die Grafikkarte eben auch 4:4:4 h264 encodieren kann. Das Keyframe-Intevall sollte auf den niedrigsten Wert eingestellt werden, also eine Sekunde. All-Intra, also nur Keyframes, kann OBS leider nicht. Mittels ffmpeg können auf der CPU auch andere Formate getestet werden, die Vorteile von zum Beispiel GoPro Cineform gegenüber h264 mit sehr hoher Bitrate sind bei 8bit Farbtiefe aber nicht spürbar.
Der Pferdefuß und die Datenbombe:
Zwar wollen alle immer Video wie im Kino machen, aber am Ende ist die Realität: YouTube. Oder, wie im Video in diesem Beispiel, wenigstens PeerTube. Auf das Video-Encoding von YouTube hat der Nutzer aber keinen Einfluss. Es wird immer auf 4:2:2 oder gar auf 4:2:0 Chroma-Subsampling rauslaufen. Das Einzige, was man tun kann: Sein Video als maximal hochwertige Datenbombe exportieren, zum Beispiel 10bit CineForm 444 (RGB) mit hoher Bitrate und diese dann bei YouTube droppen, aufdass dieses die am wenigsten schlimme Version zur Auslieferung daraus generiert.
Problem: Mein Autoradio verdaut nur MP3. Ich habe früher meine auf CD gekaufte Musik als OGG gesammelt, seit einiger Zeit sammle ich auch FLAC. Aber mein altes Ford Sync-System kann beides nicht.
(Nicht-Lösung): Eigentlich könnte alles ganz einfach sein, es hilft wie immer ffmpeg:
ffmpeg -i eingabedatei.xyz -aq 0 ausgabedatei.mp3
Das funktioniert auch für FLAC-Dateien perfekt. Auch OGG-Dateien werden konvertiert – jedoch kommen die Metadaten, die mein EasyTag da reingemacht hat, nie richtig an – selbst alte Player auf dem PC wie Clementine wissen nichts über die MP3s.
Echte Lösung: In die Vollen gehen und die Metadaten aus den OGG-Dateien rausholen und separat in die MP3-Dateien eintüten. Das geht mit folgendem Script, ich nenne es toMP3:
#!/bin/bash
# My ogg files contain metadata that does not work automatically with ffmpeg, so I need to sort it manually
function convertOGG () {
local file=”$1”
local output=”$2”
# extract metadata
local title=$(ffprobe -v quiet -show_entries stream_tags=TITLE -of default=nw=1:nk=1 ”$file”)
local artist=$(ffprobe -v quiet -show_entries stream_tags=ARTIST -of default=nw=1:nk=1 ”$file”)
local album=$(ffprobe -v quiet -show_entries stream_tags=ALBUM -of default=nw=1:nk=1 ”$file”)
local track=$(ffprobe -v quiet -show_entries stream_tags=TRACK -of default=nw=1:nk=1 ”$file”)
ffmpeg -i ”$file”
-id3v2_version 3 -write_id3v1 1
-map_metadata -1
-metadata title=”$title” -metadata artist=”$artist” -metadata album=”$album” -metadata track=”$track”
-aq 0 ”$output”
}
# FLAC metadata is simple, this works automatically
function convertFLAC () {
local file=”$1”
local output=”$2”
ffmpeg -i ”$file” -map_metadata 0 -id3v2_version 3 -write_id3v1 1 -aq 0 ”$output”
}
# WAV could have metadata, too
# TODO: This is not really tested since I don’t have WAV files that often
function convertWAV () {
local file=”$1”
local output=”$2”
ffmpeg -i ”$file” -map_metadata 0 -id3v2_version 3 -write_id3v1 1 -aq 0 ”$output”
}
f=”$1”
# Remove file extensions and add mp3
out=”$f” ; out=”${out%flac}” ; out=”${out%ogg}” ; out=”${out%wav}” ; out=”${out}mp3”
# Decide based on file contents / mime type what to do now
mimetype=$(file -b –mime-type ”$f”)
case ”$mimetype” in
”audio/ogg”)
convertOGG ”$f” ”$out”
;;
”audio/flac”)
convertFLAC ”$f” ”$out”
;;
”audio/wav”)
convertWAV ”$f” ”$out”
;;
*)
echo ”Don’t know what to do with mime type $mimetype in $f.”
exit 1
esac
Ob das auch für WAV-Dateien funzt? Das ist noch unklar. Da ffmpeg beim Encoding von Audio nicht parallelisiert / die Last auf alle Prozessoren verteilt, kann man das noch mittels folgendem find/xargs-basierten Hack abvespern, der alle OGG-Dateien im aktuellen Verzeichnis und allen Unterverzeichnissen in MP3 konvertiert.
Das setzt natürlich voraus, dass man das oben aufgeführte lange Script in der als ausführbar deklarierten Datei toMP3 in seinem Suchpfad ($PATH) abgelegt hat.
Jetzt kann ich mit meinem Autoradio hoffentlich wieder Alben hören, und nicht nur insgesamt alle Tracks auf dem USB-Stick in alphabetischer Reihenfolge der Dateinamen!
Problem: Im Plugin-Host Carla unter Linux soll ein Audio-Plugin, z.B. ein Delay synchron zu einem externen Gerät laufen, das sein Tempo per MIDI Clock kommuniziert. Carla scheint aber irgendwie mit MIDI Clock nichts anzufangen.
Hintergrund-Info: Carla nutzt Jack als Audio- und MIDI-Backend unter Linux. Jack transportiert keine MIDI-Clock-Messages über sein MIDI-System. Außerdem können viele Plugins gar nicht zu MIDI Clock synchronisieren, sondern nur zu „Host”, was heißt: Das Tempo des Plugin-Hosts. Das Tempo, das Carla annimmt und weitergibt, heißt Jack Transport. Ob nun Pipewire oder der alte Jack dahinter stecken: Wenn der Transport läuft, dann synchronisiert Carla darauf (aber: Siehe Achtung, Falle weiter unten), und wenn ein Plugin dann auf Host synchronisiert, ist es im Takt.
Lösung: Der Jack Transport muss auf die externe MIDI-Clock synchronisiert werden. Das kann mit dem Kommandozeilen-Hack midi-clock-jack-bridge geschehen. Ist das Tool installiert und in Betrieb, so muss der entsprechende MIDI-Eingang noch damit verkabelt werden – da das klammheimlich nicht über Jack MIDI, sondern ALSA MIDI passiert, geht die Clock an das Tool durch. Das bringt den den Jack Transport auf Trab und fertig ist die Laube.
Achtung, Falle: In der Welt von Jack kann es nur einen Transport Master geben. Und Carla will selbst der Master sein. Daher funktioniert die Lösung nur, wenn man zuerst midi-clock-jack-bridge startet und dann Carla. Dann sieht Carla von seinem Anspruch ab. Es kann außerdem sein, dass Carla das Tempo nicht korrekt anzeigt, solange kein Plugin die Synchronisation in Anspruch nimmt.
Pfeifendraht, galore: Diese Lösung habe ich auch erfolgreich mit Pipewire 1.4.10 getestet, was auf neueren Linux-Distributionen Jack ersetzt und zugleich vollständig kompatibel zu Jack sein will – die Anwendungen merken also nix.
Der Screenshot oben zeigt Carla und midi-clock-jack-bridge in Aktion, wobei sich das TAL DubX Delay-Plugin zum Tempo synchronisiert. (Randnotiz: Das Plugin Decent Sampler ist sehr angenehm, und es gibt viele spannende kostenfreie Sample-Bibliotheken dafür!) Der untenstehende Screenshot zeigt die virtuelle Patchbay Patchance, und die Verkabelung des USB-MIDI-Eingangs mit der Bridge.
So richtig traue ich der Lösung noch nicht, es fühlt sich hacky wacky an. Hat jemand einen Tipp, wie man die Lösung bombensolide gestalten könnte?
Problem: Ich schließe einen modernen PC mit Windows 11 an einen älteren Bildmischer an, nämlich an den Blackmagic ATEM Television Studio HD. Es kommt kein Bild, egal was ich mache.
(Nicht-)Lösung: Eigentlich genügt es, am PC genau die gleiche Bildwiederholrate und Auflösung einzustellen, wie am ATEM Studio HD. Der Switcher hat keine Framerate-Konverter und auch keine Scaler, er braucht es also genau auf den Punkt. Das liefert Windows 11 aber unter Umständen gar nie – die Ursache ist unklar, es könnte sein, dass Windows bei unklarer oder unvollständiger EDID vom Switcher immer 60Hz oder immer 4k ausgibt.
Nicht-Workaround: Einen zweiten Bildschirm am PC anschließen. Über Windows+P die Bildschirme duplizieren und auf dem zweiten Bildschirm dann die Framerate und Auflösung für den ATEM Television Studio HD korrekt einstellen. Dann funzt es – bis man den zweiten Bildschirm abstöpselt, dann konfiguriert Windows 11 alles automatisch neu und falsch. Die manuelle Einstellung der Grafikparameter bleibt nicht erhalten. Eine zuverlässige Video-Ausgabe ist nicht möglich. Betroffen sein können auch LED-Wände und andere Großspielzeuge der Veranstaltungtechnik.
Lösung: Andere Video-Hardware kaufen. Zum Beispiel den Roland V-1HD+ für 680€. Der Television Studio HD ist zwar noch gut, aber weil Windows 11 schlecht geworden ist, kann man den nun wegwerfen.
Vielleicht hilft auch ein Signalwandler wie der gute alte Decimator, allerdings bräuchte man bei mehreren Windows-Rechnern dann mehrere davon, und drei Stück sind schon teurer als ein neuer Switcher. Billige EDID-Manager-Zwischenstecker scheinen keine Framerates vorgeben zu können, oder nur 30/60Hz, keine 25/50. Auch eine bei mir vorhandene, etwas bessere HDMI-Matrix kann nur die Auflösung, nicht aber die Framerate vorgeben.
Halbe Hoffnung: Vielleicht gibt es aber auch ein Windows-Voodoo, das ich noch nicht kenne – was aber auch nur eingeschränkt nützlich wäre, da es ggf. auf Laptops des Kunden nicht anwendbar ist, da dieser auf seinem Firmen-Rechner keine vollen Zugriffsrechte hat.
Wer eine bessere Idee hat: Die Kommentare sind geöffnet.
Problem: Meine Aktivboxen knallen, weil sie schneller hochfahren, als mein Mischpult – oder eine andere angeschlossene Quelle. Also die Quelle sendet einen Knacks oder Bumms, wenn sie angeht, die Boxen sind schon da und bringen das lautstark zur Geltung, was ihnen außerdem nicht gut bekommt.
Lösung: Eine Schuko-Steckdose mit Einschaltverzögerung gibt den Aktivboxen erst einige Zeit nach dem gemeinsamen Einschalten mit dem Rest den nötigen Saft. Solche Steckdosen gibt es online zu kaufen, doch sie sind recht teuer. Sogenannte Power-Sequencer lösen das Problem auch, aber für noch mehr Geld. Allerdings ist selbst bei teuren Produkten die Verzögerungszeit nicht immer einstellbar und auch nicht immer ausreichend.
Daher: Eine Smart-Steckdose mit dem Betriebssystem Tasmota gibt es für moderat viel Geld. Man muss dann halt seine Einschaltverzögerung selber einprogrammieren.
Vorbereitung: Zunächst muss die Tasmota-Steckdose bei der ersten Inbetriebnahme ins eigene WLAN eingebunden werden. Beim ersten Einschalten taucht ein eigenes WLAN mit Name Tasmota-irgendeincode auf. Dorthin verbindet man sich, ruft http://192.168.4.1 auf und daddelt sich dort durch den Assistenten. Der bucht die Steckdose ins eigene WLAN ein und spuckt dann ihre neue IP-Adresse aus. Daraufhin verbindet man sich wieder mit dem normalen, eigenen WLAN und navigiert im Browser zur neuen IP.
In der Tasmota-Oberfläche sucht man die Console genannte Eingabeaufforderung auf, die sieht so aus:
Dort gibt man folgende Kommandos ein, jede Zeile separat:
Rule1 on Power1#Boot do RuleTimer1 30 endon on Rules#Timer=1 do Power1 ON endon
Rule1 1
PowerOnState 0
SetOption0 0
Erläuterung:
Es wird eine Regel definiert, die mit 30 Sekunden Verzögerung nach dem Event Power1#Boot den Saft einschaltet.
Die Regel wird aktiviert.
Der Tasmota-Steckdose wird gesagt, dass sie beim Anschalten noch keinen Saft abgeben soll.
Sicherheitshalber wird noch eingestellt, dass die Steckdose sich den letzten Power-Zustand nicht merken soll.
Anmerkung: Andere Lösungen, die ich im Netz gefunden habe, funktionieren erst, nachdem die Tasmota-Steckdose im WLAN eingebucht ist. Zum einen kann das an sich schon eine nicht genau definierte Weile von etwa 5 bis 20 Sekunden dauern, zum anderen könnten sich Lautsprecher und Mischpult später auch in einer Umgebung befinden, in der das WLAN nicht verfügbar ist.
Ergänzungen zu dieser Lösung werden in den Kommentaren gerne angenommen.
