스크립트
00:00:00Hier ist eine Frage: Wie sendet man jemandem eine Datei ohne Netzwerk und ohne physische
00:00:05Geräte wie USB-Sticks? Nun, die Antwort lautet optische Dateiübertragung. Ein Entwickler namens Evan
00:00:13Crawley hat gerade ein Tool namens Deciman entwickelt, mit dem sich eine Datei von einem Gerät zum
00:00:19anderen übertragen lässt, indem einfach QR-Codes aufblitzten und wieder eingelesen werden. Das ist eine super coole Technik
00:00:26zur Dateiübertragung und nutzt einige ziemlich raffinierte technische Kniffe. Im heutigen Video schauen wir uns
00:00:31Deciman an, sehen uns an, wie es funktioniert, und testen es in verschiedenen Szenarien, um herauszufinden, wie leistungsstark
00:00:37die optische Dateiübertragung tatsächlich ist. Das wird eine Menge Spaß machen, also stürzen wir uns darauf.
00:00:46Deciman funktioniert so: Ein Gerät zeigt einen Strom QR-Code-ähnlicher Frames auf seinem Bildschirm
00:00:53und ein anderes Gerät richtet eine Kamera darauf und decodiert sie wieder in eine Datei. Es ist also überhaupt kein
00:01:00Netzwerkstapel im Spiel. Wenn man jemals eine Datei mit einem isolierten Air-Gap-Gerät austauschen muss, ist dies die einzige
00:01:06Möglichkeit, ohne physisch externe Geräte wie USB-Laufwerke anzuschließen. Die Idee dahinter ist, dass man
00:01:12seine Datei als Sequenz von QR-Codes codiert, sie nacheinander auf dem Bildschirm aufblinken lässt und eine Kamera
00:01:19am anderen Ende jeden Frame erfassen und decodieren lässt. Das mag einfach klingen, aber die Komplexität ergibt sich
00:01:26aus der Tatsache, dass Kameras nicht augenblicklich aufnehmen und Bildschirme sich nicht augenblicklich
00:01:32aktualisieren. Man lässt also zwei verschiedene Hardwarekomponenten gegeneinander antreten, und wenn sie aus dem Takt geraten,
00:01:38werden Frames beschädigt oder ganz verpasst. Decimans Antwort auf dieses Problem ist jedoch eine Methode namens Fountain Coding.
00:01:46Anstatt Frame 1, Frame 2, Frame 3 zu senden und zu hoffen, dass jeder einzelne ankommt,
00:01:53erzeugt es einen praktisch unbegrenzten Strom codierter Frames, bei denen jeder Frame eine mathematische Mischung
00:02:00aus Teilen der Originaldatei ist, anstatt nur eines spezifischen Teilstücks davon. Das bedeutet, dass kein einziger Frame unersetzlich ist.
00:02:07Der Empfänger braucht nicht speziell Frame Nummer 47, er braucht einfach nur genügend Frames, ganz gleich, welche gerade ankommen.
00:02:14Und wenn man die Hälfte davon verpasst, spielt das keine Rolle. Es sendet einfach so lange weiter, bis der Empfänger genug
00:02:22gesammelt hat. Dieser Ansatz ist jedoch keineswegs ein Allheilmittel. Bei dieser Methode gibt es eine Obergrenze für die Datenmenge,
00:02:29die wir übertragen können. Standardmäßig presst Decimans Sender 2953 Bytes pro Frame bei 60 Bildern pro Sekunde durch.
00:02:37Wenn man das durchrechnet, erhält man eine theoretische Obergrenze von etwa 177 Kilobyte pro Sekunde.
00:02:44Rechnet man den Overhead durch das Fountain Coding hinzu, da einige dieser gemischten Frames von Natur aus redundant sind,
00:02:51bleibt am Ende die Zahl übrig, die in Decimans Readme-Datei tatsächlich angegeben wird.
00:02:56Sie liegt bei der Messung von Telefon zu Telefon bei einem Spitzenwert von etwa 128 Kilobyte pro Sekunde.
00:03:02Der Grund, warum speziell 2953-Byte-Blöcke verwendet werden, liegt darin, dass dies der QR-Code-Version 40 entspricht,
00:03:11der größten Standard-QR-Größe, einem Raster von 177 mal 177 einzelnen Modulen, verpackt in einen einzigen Frame.
00:03:20Genau hier zeigt sich der wahre Kompromiss. Wenn man mehr Daten in einen Frame packt, benötigt man insgesamt weniger Frames,
00:03:26um dieselbe Datei zu senden, was bedeutet, dass die lesende Kamera eine höhere Auflösung,
00:03:33eine ruhigere Hand und einen schärferen Fokus braucht, um die einzelnen Module voneinander zu unterscheiden.
00:03:38Das gesamte System ist also in Wirklichkeit ein Balanceakt zwischen drei Variablen.
00:03:42Wie viele Bilder pro Sekunde gesendet werden, wie dicht jeder dieser Frames ist und wie gut die empfangende
00:03:49Kamera tatsächlich darin ist, diese Dichte aufzulösen. Deciman liefert standardmäßig eine spezifische Abstimmung aus,
00:03:57die für genau ein bestimmtes Szenario optimiert ist – das, wie ich feststellen musste, nicht das Szenario war, in dem ich es getestet habe.
00:04:03Hier ist also mein Setup: ein Laptop-Bildschirm als Sender in normalem Abstand einer Armlänge,
00:04:09so wie man das in der Praxis tatsächlich nutzen würde. Mit diesem Setup war meine Übertragung auf etwa drei Kilobyte pro Sekunde gedeckelt.
00:04:16Ungefähr ein bis zwei Prozent der übertragenen Frames werden tatsächlich decodiert. Der Rest wird erfasst und verworfen.
00:04:23Dabei wirken nun drei Dinge gegen uns. Die erste und größte Hürde ist die Nichtübereinstimmung der Bildraten.
00:04:30Der Sender liefert 60 Bilder pro Sekunde, aber die Kamera meines Handys nimmt mit 30 auf. Man kann nicht 60 verschiedene Bilder
00:04:38mit einem Sensor abtasten, der nur 30 erfasst. Und es ist noch schlimmer, als nur die Hälfte davon zu verpassen, da das Belichtungsfenster jedes
00:04:45erfassten Frames zwei verschiedene QR-Codes auf dem Bildschirm überspannt. Die Kamera verpasst also nicht einfach sauber einen Frame, sondern vermischt zwei davon zu etwas, das sich überhaupt nicht decodieren lässt.
00:04:56Und in der Datei main.ts gibt es sogar einen Hinweis, dass iOS im Stillen 30 Bilder pro Sekunde liefert, selbst wenn die App ausdrücklich 60 von der Kamera anfordert.
00:05:07Die Kamera gibt einfach nicht das aus, was man angefordert hat, und der Code berücksichtigt das bereits.
00:05:12Und etwas weiter unten in derselben Datei findet sich ein Kommentar, der im Grunde genau das vorhersagt, was mir bei meinem ersten Versuch passiert ist.
00:05:19Die Standardeinstellungen – nämlich 2953 Bytes pro Frame bei 60 Bildern pro Sekunde – sind speziell auf eine Nahbereichs-Demo von Telefon zu Telefon abgestimmt.
00:05:29Es wird erwartet, dass dieselbe Kombination auf einem gewöhnlichen Monitor aus Armlänge Schwierigkeiten bereitet.
00:05:35Mit anderen Worten: Das Projekt hat mir gesagt, dass das passieren würde. Ich hatte nur im Code nicht weit genug nach unten gescrollt, um es zu sehen.
00:05:41Auf der Senderseite hat ein 60-Hertz-Laptop-Display das gleiche Problem in umgekehrter Reihenfolge, und LCD-Pixel brauchen viel Zeit, um Farbe vollständig von Grau zu Grau zu wechseln.
00:05:51Diese Übergangszeit bedeutet, dass das Display noch nicht vollständig bei einem Code angekommen ist, bevor der nächste beginnt, ihn zu übermalen.
00:05:58Man erhält also Geisterbilder-Artefakte. Das zweite Problem ist die Codedichte im Vergleich zur Kameraauflösung.
00:06:042953 Bytes entsprechen QR-Version 40, aber ein zuverlässiges Decodieren erfordert etwa drei bis vier Kamerapixel pro Modul, was allein für den Code selbst über 600 Pixel in der Breite bei scharfem Fokus ausmacht.
00:06:20Ein Laptop-Bildschirm in Armlänge füllt diesen Teil des Kamerarahmens eines Handys selten aus, aber von Telefon zu Telefon im Nahbereich wird der gesamte Sucher mühelos ausgefüllt.
00:06:30Das dritte Problem ist Helligkeit und Kontrast. Das ist ein sekundäres Problem, aber es hilft, wenn der Binarisierer des Empfängers das Bild sauber trennt, was jedoch eine Bildraten-Diskrepanz oder einen zu kleinen Code nicht beheben kann.
00:06:44Versuchen wir also nun dieselbe Übertragung, diesmal jedoch von einem Telefon zu einem anderen Telefon.
00:06:50Das Einzige, was sich ändert, ist der Sender. Es ist ein kleiner, heller OLED-Bildschirm in geringem Abstand, der den gesamten Rahmen des empfangenden Handys ausfüllt.
00:06:58Nun kann sich die Kamera tatsächlich ihrer realen Bildrate annähern.
00:07:02Der Code füllt den Rahmen in hoher Auflösung aus und es gibt kein LCD-Nachziehen, gegen das man ankämpfen muss.
00:07:07Unter diesem Szenario wurde die Angabe von 128 Kilobyte pro Sekunde in der Readme-Datei tatsächlich gemessen.
00:07:14Es gibt auch ein kleines, aber wirklich nützliches Detail im Code des Empfängers.
00:07:18Er meldet die Aufnahme-FPS und die Decodierungs-FPS getrennt. Die Aufnahme zeigt, was die Kamera physisch sieht.
00:07:26Die Decodierung gibt an, wie viel davon tatsächlich nutzbar ist.
00:07:30Wenn diese beiden Zahlen auseinanderdriften – die Aufnahme also stabil bleibt, während die Decodierung einbricht –,
00:07:35liegt ein Missverhältnis vor zwischen der Dichte der Frames und dem, was die Kamera in dieser Entfernung tatsächlich auflösen kann.
00:07:42Wenn also Laptop zu Telefon Ihr tatsächlicher Anwendungsfall ist, besteht die Lösung darin, diese drei Variablen auf Senderseite neu auszubalancieren.
00:07:50Man sollte die Bytes pro Frame auf 1465 reduzieren, was einer gröberen QR-Version mit größeren, fehlertoleranteren Modulen entspricht.
00:07:59Und dann die Übertragungs-FPS bewusst auf 24 senken, also unter die 30-FPS-Grenze der Kamera.
00:08:07So werden Frames sauber nacheinander abgetastet, anstatt ineinander zu verschwimmen.
00:08:12Und wie man sieht, führt das Verringern dieser Werte zu einem deutlich höheren Durchsatz.
00:08:16Das zeigt einfach, dass optische Dateiübertragung keine Einheitslösung ist.
00:08:21Man muss sie für jeden Anwendungsfall je nach verwendeter Hardware manuell anpassen.
00:08:26Da haben wir es also, Leute.
00:08:27Das ist Deciman auf den Punkt gebracht.
00:08:29Insgesamt hat es wirklich Spaß gemacht, sich in dieses Projekt zu vertiefen.
00:08:32Optische Dateiübertragung ist eine ziemlich coole Technik.
00:08:36Und es war äußerst interessant zu sehen, wie das Konzept des Fountain Codings hier in einem realen Szenario angewendet wird.
00:08:44Während ich dieses Projekt erkundete, habe ich mich auch gefragt, wo man diese Art von Tool eigentlich einsetzen würde.
00:08:49Die naheliegende Antwort sind wahrscheinlich Air-Gapped-Übertragungen, bei denen man absichtlich gar keine Netzwerkverbindung wünscht.
00:08:57Oder vielleicht Geräte, die nicht einmal Bluetooth oder WLAN besitzen, wie alte Hardware oder eingebettete Systeme.
00:09:04Kurzum: überall dort, wo ein Bildschirm und eine Kamera die einzigen Dinge sind, auf die man zählen kann.
00:09:10Aber was halten Sie von diesem Tool?
00:09:11Haben Sie schon einmal Tools zur optischen Übertragung verwendet?
00:09:14Sehen Sie dafür irgendeine reale Anwendung?
00:09:17Lassen Sie es uns unten in den Kommentaren wissen.
00:09:19Und Leute, wenn euch solche technischen Analysen gefallen, lasst es mich wissen, indem ihr auf den Daumen-nach-oben-Button unter dem Video klickt.
00:09:25Und vergesst auch nicht, unseren Kanal zu abonnieren.
00:09:28Das war Andrus von BetterStack, und wir sehen uns in den nächsten Videos.
00:09:34Wir sehen uns im nächsten Video.