Bino: der 3D Videoplayer

Bei Linux am Dienstag hatten wir jetzt zwei Wochen lang Spaß mit 3D Bildern, da wird es Zeit Euch daran teilhaben zu lassen 😉  In Teil 1 der neuen Miniserie, befassen wir uns mit Bino, dem 3D-Videoplayer. Dann mit FFMPEG und den spannenden Möglichkeiten, die sich damit bieten.

Bino: der 3D Videoplayer

Wer war schon in den 80ern auf der Welt und hat noch eine Rot-Grünbrille von Damals? 🙂 Die, oder besser die moderne Version in Rot-Cyanblau, werdet Ihr gleich brauchen:

Szene aus „Alice in Borderland 2020“ IMDB

BINO kann aus 2D Material 3D Material machen, aber das kostet uns etwas.

Das hier angewandte Verfahren, analysiert die Pixelbewegung zwischen zwei aufeinander folgenden Bildern. Je nach der Geschwindigkeit der Pixelbewegung, also wieweit die in einem Frame gekommen sind, werden die zwei Bilder zu einem Mischbild verrechnet und die bewegten Pixel in Rot bzw. Cyanblau eingefärbt. Man sieht das ja oben im Bild. Durch die Brille sieht man jetzt jeweils auf einem Auge nur eine der beiden Farbe, die sehr genau ausgefiltert sein müssen, damit möglichst viele andere Farben in dem Bild „sauber“ durchkommen.

Wer sich das Bild oben ohne Brille ansieht, der erkennt das natürlich sofort 😉 mit Brille sieht das schon viel „besser“ aus. Achtet bei dem Testbild mal auf die Schulter von der Person im Vordergrund, die springt mit Einsatz der Brille förmlich vom Hintergrund weg und der 3D Effekt zeigt sich ganz deutlich.

Verluste sind eingepreist

Um diesen Effekt zu bekommen, werden ja zwei Bilder verglichen. Leider ist der von Bino eingesetzte Algorithmus nicht der allerbeste, was als Konsequenz bedeutet, wir verlieren 50% der Frames. Bei einer 30 FPS Aufnahme, fängt das Bild beim Abspielen dann an zu rucken wie in den 10er Jahren des letzten Jahrhunderts. Das ist weniger schön, aber kompensierbar, wenn man 60 FPS Material benutzt. Es verursacht auch auf Dauer böses Kopfweh.

Aufgrund der eingesetzten Methode durch bestimmte Farben, sieht das Bild nicht mehr normal aus, deswegen hat man ja dann in den 2000er Jahren die Polarisationsgläser im Kino eingesetzt, die das Farbsehen nicht beeinflussen. Auf einem normalen Monitor kann man solche Brillen aber nicht einsetzen, dazu braucht es dann spezielle 3D Monitore, die mittlerweile ziemlich rar gesät sind. VR Brillen füllen diese Lücke, sind aber finde ich, zu teuer um sich da mal einen Spaß zu machen.

Dem Algorithmus is auch geschuldet, daß Bildteile, die sich nicht bewegen, keinen 3D Effekt erzeugen. Das kann Bino aber ein bisschen ausgleichen in dem es eine Kantenerkennung einsetzt und dort perspektivische Pixelverschiebungen erzeugt:

geht auch bei Standbildern

Den Parallaxenwert zu hoch zusetzen ist sinnlos, 0,01 – 0,05 reichen völlig aus für einen Tiefeneindruck. Dieser kleine Trick macht das Erlebnis etwas besser, ist aber zu einem Film, der in 3D gedreht wurde, kein Vergleich.

Bino kann aber noch mehr

Bino kann als Bildquelle auf Webcams benutzen, so daß man sich, oder etwas, in 3D bewundern kann, vorausgesetzt man bewegt sich ausreichend 😀 Leider kann man das Bild nicht live exportieren, also nicht in einer Videokonferenz benutzen. Das ist aber die perfekte Überleitung zum nächsten Artikel der Serie: „Mit FFMPEG zur Live 3D Videokonferenz“ 😀

Programmtechnisch hat Bino leider auch noch ein paar kleine Bugs, z.b. muß man alle Werte neu setzen, wenn man einen neuen Film lädt. Auch macht die GUI nicht mit, wenn man über das Menü einen Film laden will, werft den stattdessen via Drag&Drop auf das Programmfenster, das funktioniert zuverläßig.

Update: Teil 2

FFMPEG: 2D zu 3D in Echtzeit

 

 

Firefox Update 57 -> 96 – keine gute Idee

Admins reden sich den Mund fusselig, aber einige Benutzer interessieren sich einfach nicht für Updates der von Ihnen genutzen Software. Was das für Firefox bedeuten kann, beleuchten wir heute.

Firefoxupdate 57 -> 96 – keine gute Idee

Vor ein paar Wochen sollte ich einen defekten Laptop retten.. es war hoffungslos :

Totalschaden

Da haben wir, auch aufgrund des Alters, einfach einen neuen bestellt. Leider hatte der neue nur noch M2 Schnittstellen, aber keine internen SATA Anschlüsse mehr. Also mußte das OS auf eine SSD geclont werden, was an sich eine leichte Übung ist.

Das N15 Acer Extensa EX215-51-52AW

Das mit einem i5 10te Generation, 8GB Ram sowie 256 GB M2.SSD ausgestattete ist ein nettes Gerät, wenn man denn Linux darauf installieren könnte. Natürlich habe ich eine LiveDisk reingesteckt, konnte aber die versprochene SSD nicht finden, egal mit welcher Distro ich es probierte 🙁 Auch im Bios tauchte das Gerät nicht auf. Sachen gibt es.

Stunden später tauchte einem ACER-Forum ein Beitrag auf, daß jemand glaubt vergessen hatte, den Raidmodus des Controllers auf AHCI umzustellen, nur leider gab es da keine Möglichkeit zu im Bios des Geräts.. dachte ich.. eine Weile.. dann stolperte ich immer wieder über diesen Artikel und beiläufig erwähnte jemand eine geheime Tastenkombination, die diesen Wechsel überhaupt erst möglich machte.

Und tatsächlich, die Kombination gab es wirklich: CTRL-s

Danach war es ganz leicht, weil sich die SSD endlich meldete. Ein externer SATA-Adapter und ein DD später bootete das Laptop die bisherige Installation. Datenverluste: 0.00 .. so lob ich es mir. Dann der Schock, nicht ganz so unerwartet 😉 Das installierte OS hatte seit 5 Jahren keine Updates gesehen. Eine wandelnde Sicherheitslücke. Installiert war noch Fedora 25 und somit ein Firefox 57, was uns zum eigentlichen Thema des Artikels führt 🙂

5 Jahre keine Updates

Natürlich habe ich in großen Schritten von Fedora 25 auf Fedora 35 aktualisiert. Das Laptop ist echt schnell, also haben 5 Distributionsupgrades nur 2h gedauert ( man muß es ja auch mal runterladen ). Dabei wurde der Firefox von 57 auf 96 aktualisiert, allerdings nur der Firefox, nicht das Profil. Als der Kunde dann seinen neuen Laptop ausprobierte, waren alle Bookmarks, Logins und Passwörter weg. 5 Jahre ohne Updates gehen an keinem Programm spurlos vorbei. Merke: UPDATEN ! UPDATEN ! UPDATEN !

Nun waren die Logins und Passwörter noch in den Profildatenbanken enthalten, es kam aber nichts mehr raus, und kurioserweise ging auch nichts mehr rein.Die übliche Lösung, ein neues Profil anlegen und Key4.db, logins.json und places.db zu kopieren, half nichts, also mußte Mozilla ran. Zur großen Überraschung von den beteiligten Mozilla Devs gab es den Fehler auch bei Ihnen: Beweisvideo von Mozilla

Ein paar Wochen später stand fest: Man kann nicht von 57 auf irgendwas 73+ updaten, ohne daß es zum kompletten Verlust kommt. In Version 72.0.2 wurden die Datenbanken des Profiles intern umstrukturiert und sind damit zu früheren Versionen inkompatibel.

Der Workaround

Der Workaround sieht vor, einfach auf Version 72.0.2 zu downgraden, den dort befindlichen Updatevorgang durch Start von Firefox zu aktivieren und dann die Versionen wieder auf 96, oder jetzt schon 97, hochziehen.

Mit Fedora ist das eher schmerzlos von einem erfahrenen Benutzer zu machen, für Laien aber zu schwierig. Da der Kunde alle seine Passwörter schon von Hand eingegeben hatte, was auch nicht ganz ohne war, gab es für Mozilla und mich nichts mehr zu tun.

Gehen wir das mal theoretisch durch:

su root
dnf downgrade firefox –releasever=32
exit
firefox
su root
dnf update firefox -y

Das wäre es schon. Es könnte sein, daß auf dem Weg noch andere Pakete mit downgegraded werden müssen, was im Einzelfall bei der Zeitspanne von 2,5 Jahren echt spannend sein wird. Natürlich gibt es eine bessere Lösung:

Installiert Euch ein altes System in eine CHROOT-Umgebung 🙂

DNF ist in der Lage eine komplette Basisinstallation in ein beliebiges Verzeichnis vorzunehmen, einfach mit –installroot pfadname angeben. Wenn man da Firefox als Wunschpaket mit angibt, dann zieht das alle Pakete nach, die man dazu braucht, auch einen Desktopmanager usw. Achtet darauf, daß es der gleiche ist, wie der, der gerade läuft, weil Ihr dann natürlich kein System im System mehr startet müßt, was eh nicht geht.

In der Chroot-Umgebung wird dann einfach das alte Profil ins Home kopiert und der Firefox gestartet. Problem gelöst.

Noch bessere Methode

Nichts geht über eine Iteration von Ideen hinaus, oder? 🙂 Vergesst einfach die Chroot, ist viel zu viel Aufwand dafür. Macht Gnome-Boxen auf, startet eine alte, versionsmäßig passende, LIVE-Disk von Eurer Distro, aktualisiert den Firefox auf die 72.0.2 und dann schiebt z.b. per SCP das Profil in die Box und startet den Firefox. Idealerweise legt Ihr vorher noch passend einen Benutzer gleichen Namens an, damit die Pfade stimmen, aber das sollte auch ohne gehen. Danach das geänderte Profil in Eurer Home verschieben. Fertig.

An die Updatemuffel dieser Welt

Eure Strategie ist genauso, wenn nicht noch, riskanter als einfach die Updates mitzumachen!

Sollte nämlich mal ein Update unter Linux nicht laufen, kann man mit einem einfachen Downgrade zurück und schon geht es wieder, außer der Bug wäre in einer Version wie 72.0.2, die die Datenbank an das neue Format anpasst, dann ist das Profil erst einmal unbrauchbar geworden. Deswegen.. Backups! Backups! Backups!

Synapse 1.51+ mit schwerem Empfangsfehler

Marix Synapse Implementierung hat einen schweren Bug in den Versionen 1.51 und 1.52, der dazu führt, daß keine Nachrichten mit bestimmten Eigenschaften ( Verschlüsselung ) beim Empfänger ankommen.

Synapse 1.51+ mit schwerem Empfangsfehler

Kurios macht diesen Fehler, daß er nur bei Externen Nachrichten auftaucht. Schickt man intern Nachrichten von einem Account zum Anderen, kommen die Nachrichten trotzdem an.

Um festzustellen, daß Ihr betroffen seid, reicht es im Log des Homeservers nach diesen Fehlermeldungen zu suchen:

2022-02-09 00:00:41,933 - synapse.federation.transport.server.federation - 114 - ERROR - PUT-34443 - 'dict' object has no attribute 'edu_type'
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/twisted/internet/defer.py", line 1661, in _inlineCallbacks
    result = current_context.run(gen.send, result)
StopIteration: 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/twisted/internet/defer.py", line 1661, in _inlineCallbacks
    result = current_context.run(gen.send, result)
StopIteration: {'ed25519:a_iiuD': FetchKeyResult(verify_key=<nacl.signing.VerifyKey object at 0x7fc8a5af6d90>, valid_until_ts=1644443665400)}

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/synapse/federation/transport/server/federation.py", line 101, in on_PUT
    device_list_updates = [
  File "/usr/lib/python3.9/site-packages/synapse/federation/transport/server/federation.py", line 104, in <listcomp>
    if edu.edu_type in DEVICE_UPDATE_EDUS
AttributeError: 'dict' object has no attribute 'edu_type'

Die Folge, Nachrichten mit diesem Attribute kommen nicht an, weil es einen GEHEIMEN! Defaulteintrag zu einem nicht standardmäßig konfigurierten Logger gibt! Ja, richtig gelesen: Weil die Nachrichten geloggt werden sollen, kommen Sie nicht an, weil das Pythonscript vorher crasht.

Die Lösung für das Problem

Die Lösung ist sehr einfach, was man auch in diesem Commit nachlesen kann:

Öffnet die Datei log_config.yaml und ändert Sie so:

loggers:
       synapse:
            level: ERROR
            handlers: file

       synapse.8631_debug:
            level: ERROR

Danach Synapse neustarten und das war es schon. Wenn Ihr betroffen ward und kein scheues Rehlein, sondern ein Matrix Hengst seid, bricht dann leider ein wahrer Sturm über Euren Server ein, weil alle anderen Server Euch gern die verpassten Nachrichten zustellen wollen. Kurzfristige Loadwarnungen sind zu tolerieren 😉