Neulich hatte ich mir Gedanken darüber gemacht, wie man beliebige Daten in Youtube-Videos kodieren könnte. Immerhin bietet 4K mit 60fps viel Raum und Youtube limitiert nicht den Speicherplatz pro Nutzer. Ich bin darauf verfallen, jedes Bild aus 2×2 Pixeln großen Kacheln aufzubauen, die jeweils mit einer Farbe aus einer Palette von f Farben aufgebaut sind. Ein Wert von 16 für f schien mir angemessen, um trotz Farbverfälschungen durch die verlustbehaftete Kompression die Farben noch eindeutig identifizieren zu können.

Einen Tag später kommt das Fraunhofer Institut mit einem neuen „Barcode“ (ist eigentlich keiner) um die Ecke, der das gleiche Prinzip nutzt. Aber das nur am Rande, zunächst weitere Überlegungen zum Speichern beliebiger Daten in einem Video.

16 Farben kodieren 4 Bit. Man kann in einem 4K-Bild mit einer Auflösung von 3.840×2.160 Pixeln 2.073.600 solcher Kacheln unterbringen, also eine Informationsmenge von 8.294.400 Bit. Das sind etwa 0,989 MiB (ein MiB ist etwa ein Megabyte). Bei 60 fps (Bildern pro Sekunde) sind das etwa 59,33 MiB pro Sekunde Video.

Die Probleme

Ich nehme an, dass durch die maximale Bitrate von Youtube alles sehr verschwimmen könnte. Entscheidend bleibt, dass die Kacheln nicht zu sehr verwischen und die Farben unterscheidbar bleiben, auch falls sie deutlich verfälscht würden. Sollten die Effekte der verlustbehafteten Kompression zu groß sein, könnte man die Größe der Kacheln und die Anzahl der Farben natürlich beliebig anpassen.

Manchmal komme ich sogar darauf, zu recherchieren, ob andere Leute ähnliche Ideen hatten. Das Projekt cryptovid nutzt QR-Codes, um die Informationen zu kodieren. Das ist bequem und nutzt verfügbare Techniken, hat aber eine geringere Datendichte. Das Projekt Matlab-Data-Video-Converter nutzt eine andere Technik (dazu unten mehr). Auf der Projektseite wird ein Problem genannt:

Note, that parameter that achieves the highest data rate appears to be bs_x = 8, bs_y = 8, repeat = 2. If you set the parameter higher than that, Youtube refuse to accept the video.

Ich bin nicht sicher, ob der Autor mit „higher“ wirklich die Größe der Parameterwerte meint, oder die erreichbare Anzahl an Blöcken und unterschiedlichen Bildern („repeat“ bestimmt, wie oft das Bild wiederholt wird, was effektiv die fps mindert), welche zu einer höheren Datendichte führen würden. Es erscheint jedoch sinnvoll und nicht überraschend, dass seitens Youtube Videos, die sich sehr schlecht komprimieren lassen, abgelehnt werden. Der Codec von Youtube ist auf foto-ähnliches Bildmaterial, nicht auf Grafiken mit zahllosen harten Kanten optimiert.

Praxistest

Zum Test habe ich ein frei verfügbares Bild von pixabay.com mittels Matlab-Data-Video-Converter zu einem Video kodiert. Dieses Projekt verwendet eine schlichte Schwarz-Weiß-Kodierung (1 Bit pro Kachel). Das Bild hat eine Dateigröße von 731,9 KiB.

Die Kodierung sieht wie folgt aus. Man kann hier die Parameter des Videos erkennen.

Das Ergebnis ist ein sehr anstrengendes Video mit einer Dateigröße von 2,9 MiB.

Um zu prüfen, ob alles funktioniert hat, gebe ich ./mp42file.sh forest.mp4 forest_decoded.jpg ein. Das Ende der Konsolen-Ausgabe:

Eine Sichtprüfung der Datei forest_decoded.jpg zeigt, dass es anscheinend funktioniert hat. Den endgültigen Beweis liefern die identischen Prüfsummen:

md5sum ../forest-931706_1920.jpg forest_decoded.jpg
da440a9a369a7808c2abb383123c02d1 ../forest-931706_1920.jpg
da440a9a369a7808c2abb383123c02d1 forest_decoded.jpg

Fazit

Das Prinzip funktioniert nachweislich. Bei den bestehenden Lösungen wird jedoch leider Datendichte verschenkt, da die Farbdimension ignoriert wird. Gnadenlose Optimierer würden zusätzlich die Tonspur und die Untertitel des Videos in so vielen Sprachen und mit so viel Text wie möglich nutzen.