Dateien über Videoanbieter wie Youtube?

[NeWsOfTzzz]

Dateien über Videoanbieter wie Youtube?

Also, Youtube und ähnliche sind ja so nett und codieren meine Videos um, wenn das Format falsch ist oder wenn z.b. die Qualität zu hoch ist. Ich vermute mal, dass wenn man das richtige Format und die maximale Qualität kennt, würde der Videoanbieter das Video nicht NOCH einmal codieren auf das selbe Level. Wenn das geht, müsste natürlich noch einer überprüfen, könnten wir uns doch mal dransetzen und ein kleines Proggie setzen, dass eine Datei (ZIP-Archiv etc.) in einen Film "codiert" und wir hätten einen guten Filehoster ohne Wartebegrenzung?

"We recommend the following settings:

* MPEG4 (Divx, Xvid) format
* 320x240 resolution
* MP3 audio
* 30 frames per second
"

Mir is gerade eingefallen, dass die das ins FLV Format codieren.. also zumindest Youtube, dadurch denke ich mal ändert sich zwangsläufig das Format. Wenn es sich ändern sollte, dann hier noch ein Lösungsweg:
In den 30 Bildern pro Sekunde einfach 160*120(19200) oder 80*60(4800) Kästchen [bei 80*60 wären die Felder 4*4 Pixel groß, sollte genügen um Bildfehler auszuschließen] einzufügen, die dann jeweils 256 verschieden Farbwerte haben könnten. bei 80*60 pro Bild und 30 FPS hätten wir dann ungefähr 140 kb pro Sekunde Film. In 5 Minuten Film könnte man so ungefähr 42 MB einbauen...

Bin mal gespannt auf eure Meinungen sowie eventuelle technische Probleme..
Ich hab mich in den Bereich (vor allem Filmkodierung) jetzt nicht so wirklich eingearbeitet, war eher ne spontane Idee!

 

[Karl Nickel]

Von der Idee her gar nicht mal so schlecht. Nur arbeitet das Flash Video Format doch ähnlich wie AVI und dient auch nur als Container. Sprich egal was du hochlädst, es wird umgewandelt. Wenn YouTubo & Co. MPEG erwartet, bringt es nicht mal was, ein "Video" als FLV hochzuladen, da es gar nicht akzeptiert wird. Und ob beim Umkonvertieren des MPEGs zu FLV von den versteckten Daten noch was übrig bleibt, wage ich zu beweifeln. Was vielleicht funktionieren könnte ist, Daten in Bildinformationen umzuwandeln, diese als MPEG abzuspeichern und dann hochzuladen. Diese Bildinformationen müsste man dann nur noch auslesen und anschließend in Daten umwandeln. Wenn man von den reinen Bilddaten ausgeht, wäre es sogar egal, wenn das Video kombrimiert wird. Man könnte ein Programm basteln, dass ein Archiv oder eine andere beliebige Datei in ein "Ameisenkrieg"-Video umwandelt, die schwarzen und weisen oder farbigen Blöcke stellen die Bits und Bytes der Datei dar und können anschließend - unabhängig vom Ausgangsformat - wieder in Daten umgewandelt werden. Also so, wie du es eigentlich beschrieben hast Man müsste die Daten noch nicht einmal von YouTube herunterladen. Es würde schon reichen, wenn man ein Screen-Capture-Programm über das Video legt und es einfach abspielt. Das Programm liest dann Frame für Frame den Ameisenkrieg aus und reproduziert somit die Daten. Wie geil, sowas sollte man patentieren lassen. Also rein theoretisch funktioniert das schon, aber ob man das so auch umsetzen kann - keine Ahnung

[edit]
Es würde eigentlich schon reichen, wenn das Programm viele kleine Bitmaps aus der Datei erzeugen würde. Mit diesen Bildern kann man ja mit Video-Tools einen Film zusammenbauen. Wichtig ist halt nur die Reihenfolge - ansonsten gehen die Dateien kaputt

 

[NeWsOfTzzz]

Naja schwarz-weiß nicht, sollten entweder 16 Farbwerte sein (entspricht 4 Blöcke in schwarz-weiß) oder wenn die Qualität reicht sogar 256 Farbwerte (entspricht 8 Blöcken [=Byte] in schwarz-weiß)

Also ich fänd's echt geil wenn's geht und wir könnten ja ne Boardexklusive Uppersoftware schreiben.. Boardexklusiv deswegen, sobald sich die Idee zu weit verbreitet, wird Youtube was dagegen unternehmen!

 

[Karl Nickel]

Gibt es bei YouTube eigentlich eine Beschränkung, wie lange ein Video dauern darf? Kenne mich damit gar nicht aus

Ansonsten guck ich vielleicht morgen mal, wie man aus Daten ein Bild machen kann. Byte für Byte sollte das eigentlich keine große Sache sein - ich hab momentan nur nicht so viel Zeit. Aber für einen kleinen Prototypen AKA Machbarkeitsstudie sollte es reichen. Wir sollten uns vielleicht auf 16 Farben beschränken, die zueinander möglichst kontrastreich sind, um Auslese-Fehler zu vermeiden. Dann könnte man auch pro Farbe einen Pixel verwenden und bekommt so mehr Daten in ein Frame ... hmm, mal schauen, wie das klappt

Wäre auf alle Fälle eine starke Sache, wenn das funktioniert :löl:

Man könnte in einer Final-Version natürlich auch so Sachen wie Kodierung und ähnliches mit einbauen. So können nur Personen, die ein Passwort haben, die Bilder in Daten umwandeln. Andernfalls haben sie jede Menge Datenschrott auf der Platte. So könnte man sich auch der YouTube-Aufsicht entziehen. Obwohl sie wahrscheinlich so ein Ameisenkrieg-Video eher als Spam deklarieren würden und deswegen löschen. Man könnte natürlich auch nur einzelne Frames mit Daten vollladen, aber ein Großteil der restlichen Frames sind tatsächlich ein sinnloses Video. Das gelegendliche Flackern könnte man als Bildfehler verkaufen und es fällt nie auf, dass da tatsächlich Daten dahinter stecken. Das perfekte "Verbrechen" (die Software, falls es sie wirklich mal geben sollte, ist natürlich nur für legale Up- und Downloads gedacht :fuck: ), dass man kaum nachweisen kann :ätsch:

 

[NeWsOfTzzz]

Also pro Farbe ein Pixel kannste vergessen, wir müssten schon mindestens Blöcke von 2*2, 3*3 oder 4*4 haben.. wegen der Kodierung des Films.. da geht zuviel verloren.
PS: Des mit den Bildern so in nem sinnlosen Film verstecken is zwar toll, aber dann haben wir wirklich nicht mehr viel übrig an Daten... vllt. 1 MB auf 5 Minuten Film
PPS: Limits bei Youtube: 100 MB und 10 Minuten
PPPS: Online videos: From home videos to premium internet television content | Veoh Video Network scheint geil zu sein.. vor allem mit diesem VEOH Player, der prinzipiell P2P benutzt

 

[Karl Nickel]

Hmmm, 1x1 Pixel klappt schon, denke ich, da wir sehr kontrastreich arbeiten. Selbst wenn die Farben leicht verwaschen werden, sollte immer noch genug schwarz und weis pro Pixel übrig sein, um auf die ursprüngliche Farbe rückschließen zu können. Aber das muss man mal ausprobieren. Momentan geht's ja nur um die Machbarkeit

Ich hab mal in PHP schnell einen kleinen Code zusammengefrickelt, der eine Datei binär einliest und in Bits (11001010 = schwarz, weis, schwarz, schwarz, ...) umwandelt. Klappt soweit ganz gut...

function encode($file = '') {
    if(file_exists($file)) {
        $pointer = fopen($file, 'rb');
        if($pointer !== false) {
            $offset = 0;
            $length = filesize($file);
            while($offset < $length) {
                $buffer = fread($pointer, 1);
                echo $buffer. "\n" . ' =byt->hex= ' . bin2hex($buffer) . "\n" .
                                     ' =hex->dec= ' . hexdec(bin2hex($buffer)) . "\n" .
                                     ' =dec->bin= ' . decbin(hexdec(bin2hex($buffer))) . "\n" .
                                     ' =bin->hex= ' . dechex(hexdec(bin2hex($buffer))) . "\n" .
                                     ' =hex->byt= ' . pack('H*', dechex(hexdec(bin2hex($buffer)))) . "\n" .
                              "\n\n";
                $offset++;
            }
            fclose($pointer);
            return null;
        }
    }
    die('Encode: File not found "' . $file . '".');
}

... und auch die Umwandlung der Bits zurück nach Bytes klappt IMHO problemlos. Hier mal ein Beispiel, was das Script bei einer Textdatei mit "Hallo Welt!" ausgibt:

H
 =byt->hex= 48
 =hex->dec= 72
 =dec->bin= 1001000
 =bin->hex= 48
 =hex->byt= H


a
 =byt->hex= 61
 =hex->dec= 97
 =dec->bin= 1100001
 =bin->hex= 61
 =hex->byt= a


l
 =byt->hex= 6c
 =hex->dec= 108
 =dec->bin= 1101100
 =bin->hex= 6c
 =hex->byt= l


l
 =byt->hex= 6c
 =hex->dec= 108
 =dec->bin= 1101100
 =bin->hex= 6c
 =hex->byt= l


o
 =byt->hex= 6f
 =hex->dec= 111
 =dec->bin= 1101111
 =bin->hex= 6f
 =hex->byt= o


 
 =byt->hex= 20
 =hex->dec= 32
 =dec->bin= 100000
 =bin->hex= 20
 =hex->byt=  


W
 =byt->hex= 57
 =hex->dec= 87
 =dec->bin= 1010111
 =bin->hex= 57
 =hex->byt= W


e
 =byt->hex= 65
 =hex->dec= 101
 =dec->bin= 1100101
 =bin->hex= 65
 =hex->byt= e


l
 =byt->hex= 6c
 =hex->dec= 108
 =dec->bin= 1101100
 =bin->hex= 6c
 =hex->byt= l


t
 =byt->hex= 74
 =hex->dec= 116
 =dec->bin= 1110100
 =bin->hex= 74
 =hex->byt= t


!
 =byt->hex= 21
 =hex->dec= 33
 =dec->bin= 100001
 =bin->hex= 21
 =hex->byt= !

Mit binären Daten sollte es auch funktionieren. Die Frage ist nur, ob die Dateien nach der Rückumwandlung auch noch lesbar sind. Aber eigentlich schon

Das umwandeln der Bytes zu Binärzahlen hat allerdings einen Nachteil. Wir benötigen, um die Bytes voneinander zu trennen, ein Trennungszeichen. Beispielsweise einen roten Pixel. Das kostet zwar Speicherplatz, aber die Zahlen, auf die ich komme, sind einfach nur krank:

Pro Frame (320x240) haben wir 76800 Pixel
Das macht 76800 Bits - 9600 Trennungs-Bits, um die Bytes zu trennen
Effektiv haben wir also 67200 Bits pro Frame (8400 Bytes oder 8,2 Kilobyte)
Pro Sekunde wären das * 30 Frames = 246 Kilobyte
Pro Minute (* 60) schon 14760 Kilobyte oder 14,41 Megabyte
In 10 Minuten Film wären das 144,14 Megabyte

Kann das sein? Hab ich mich verrechnet? Weil so würde ja jeder kleinkombrimierte Film mehr Daten schlucken, als ein gewöhnliches ZIP-Archiv. Kann ich mir aber nicht so wirklich vorstellen...

 

[peter9876]

wenn schon so ein projekt wäre es dann nicht möglich so eine zip oder rar datei einzubinden das ist wahrscheinlich einfacher zu realisieren als eine .exe in ein bitmap zu codieren

 

[NeWsOfTzzz]

Das Problem ist, dass du glaubst, dass die Qualität wirklich so gut wäre, dass man jeden Pixel einzeln nehmen kannst ^.-
Musst schon Blöcke nehmen..

 

[Karl Nickel]

@peter:
Du meinst als "Anhang" mit einfügen? Das funktioniert nicht, weil die Video-Hoster die Dateien umwandeln. Eingebettete Informationen gehen hierbei höchstwahrscheinlich verloren. Daher macht es schon Sinn, die Daten in Bildinformationen umzuwandeln. Und wieso soll das umständlich sein? Schau dir mal den PHP-Code oben an. Das Einzige, was noch fehlt ist, die Binär-Zahl in ein Schwarz-Weis-Bild umzuwandeln und das macht auch nicht die Welt aus. Klar, später muss man daraus noch eine richtige win32-Anwendung machen, aber sonst ist das eigentlich kein Problem. Einzige Schwierigkeit, die ich sehe, ist das "Abnehmen" der Bildinformationen bei den Filehostern. Da muss ich mal schauen, wie gut das klappt. In normalen Playern funktioniert das in der Regel nicht.

BTW hab ich mal ein 1x1-Pixel-Bild von Hand angefertigt. Mit Photoshop in schlechtester JPEG-Qualität gespeichert und anschließend mit dem Movie Maker ein WMV-Filmchen draus gemacht. Beim Abspielen hat es zwar einen komischen Moire-Effekt, aber die Pixel sind einzeln zu erkennen. Eine Software dürfte die optische Täuschung eigentlich nicht stören. Was aber wichtig ist, wir können rein theoretisch 144 Megabyte in so ein kleines Filmchen packen. Und das sind nur die Bildinformationen. Die Toninformationen kann man natürlich auch noch mit Daten füllen. Allerdings hört hier mein Horizont auf - das wird mir zu kompliziert

 

[Karl Nickel]

@NeWsOfTzzz
Kannst du mal ein Schwarz-Weis-Raster 1x1 Pixel auf ein 320x240-Video legen und bei YouTube hochladen - hab da nämlich (noch) kein Account. So können wir mal schauen, wie das mit der Qualität aussieht.

Übrigens funktioniert das Script oben nicht mit Binärdaten, sondern nur mit reinen Textdaten. Das Problem ist, dass PHP mit 8-Bit-Zeichen in den Binärdaten nicht richtig umgehen kann und falsch ausliest. Das Resultat ist eine kaputte Binärdatei. Allerdings ist das nicht nur ein Problem in PHP, sondern auch andere Programmiersprachen sind davon betroffen. Die normalen Funktionen zur Textverarbeitung sind nicht in der Lage, mit 8-Bit-Zeichen umzugehen. Daher muss man den Inputstream mit Base64 kodieren, um die Daten mit den normalen Funktionen zur Textverarbeitung beareiten zu können. Dadurch werden die eigentlichen Daten aber um ca. 30% aufgebläht. Das heißt, wir bekommen höchstens 100 Megabyte in ein Video, wenn wir pro Pixel ein Bit speichern. Eine andere Möglichkeit wäre allerdings, pro RGB-Wert eines Pixels Daten zu speichen. Dadurch können wir 3 Bits pro Pixel speichern und erhalten dadurch die dreifache Speichermenge - 300 Megabyte

Wie funktioniert's? Ganz einfach. Ein RGB-Wert besteht aus drei Werten 0-255. Ein Bit besteht au zwei Zuständen 0 und 1. Das portieren wir nun auf den RGB-Wert. Somit erhält unser Bit die Zustände 0 und 255 und unsere Pixel kontrastreiche Farben. Und wir speichern das dreifache an Daten in einer Seite

 

[NeWsOfTzzz]

BTW hab ich mal ein 1x1-Pixel-Bild von Hand angefertigt. Mit Photoshop in schlechtester JPEG-Qualität gespeichert und anschließend mit dem Movie Maker ein WMV-Filmchen draus gemacht. Beim Abspielen hat es zwar einen komischen Moire-Effekt, aber die Pixel sind einzeln zu erkennen.

Das zeigt nur, dass du keien Ahnung hast, wie Filme kodieren ^^
Es gibt hin und wieder ein Keyframe(kann man einstellen bei welchem Frame der ist, normal is so 5-80), der alle Bildinformationen enthält.
Das, was der Codec dann speichert, ist die Information wie das Bild sich bei jedem Frame ÄNDERT. Ansatz basiert darauf, das in den meisten Filmen ein großer Teil des Bilds gleichbleibt oder sich nur ein bisschen verschiebt. Das heisst natürlich, wenn du ein Film drehst mit einem statischen Bild.. na super
Wenn du jetzt bei jedem Frame ein komplett anderes Bild hast, dann wird's problematisch. Wenn man dann noch das downsamplen der Videoanbieter betrachtet.. wird's richtig kritisch

 

[Ralph Peter]

Wie funktioniert's? Ganz einfach. Ein RGB-Wert besteht aus drei Werten 0-255. Ein Bit besteht au zwei Zuständen 0 und 1. Das portieren wir nun auf den RGB-Wert. Somit erhält unser Bit die Zustände 0 und 255 und unsere Pixel kontrastreiche Farben. Und wir speichern das dreifache an Daten in einer Seite

das macht aber 24 bit pro pixel und nicht 3, denn um 255 verschiedene Farbtabstufungen pro Farbkanal darzustellen, brauchst du nicht 1, sondern 8 bit.

 

[Karl Nickel]

@ Ralph:
Ist klar, allerdings speichere ich Daten als Farbwerte. Und da ich Kontrastreiche Farben brauche, kann ich für R, G und B entweder nur 0 oder 255 verwenden, was bei einem Bit 0 oder 1 entspricht. Also sind's IMHO 3 Bit Daten pro Pixel. Bei normaler Verwendung der RGB-Werte hast du natürlich recht

@NeWsOfTzzz
Hm, das ergibt natürlich Sinn - und ja, ich habe tatsächlich keine Ahnung von Video-Kodierung

Ich habe die PHP-Funktion dennoch mal weitergesponnen. Diese Prototyp-Funktion hier ist in der Lage, Binärdaten in Bilddaten umzuwandeln:

<pre>
<?php
//
// $input
//   Pfad zur Datei, die umgewandelt werden soll
// $output
//   Pfad zum Ausgabeverzeichnis
// $size
//   Größe der Bits im Frame (1 = 1x1 Pixel, 2 = 2x2, ...)
// $width
//   Breite des Frames
// $height
//   Höhe des Frames
//
function bin2img($input, $output = '', $size = 1, $width = 320, $height = 240) {
    // Prüfen, ob Datei existiert und lesbar ist
    if((file_exists($input) && is_readable($input)) && is_dir($output)) {
        // Datei einlesen und nach base64 kodieren, um die Binärdaten zu erhalten
        $buffer = base64_encode(file_get_contents($input));
        // Buffer zur Weiterverarbeitung splitten
        $buffer = str_split($buffer);
        // Container für Binärdaten (Bits)
        $binary = null;
        // Buffer (Bytes) in Bits umwandeln
        foreach($buffer as $byte) {
            // Hex-Wert des Bytes ermitteln
            $tmp_hex = bin2hex($byte);
            // Umwandlung des Hex-Werts in eine Decimalzahl
            $tmp_dec = hexdec($tmp_hex);
            // Umwandlung der Decimalzahl in eine Binärzahl (Bits)
            $tmp_bin = decbin($tmp_dec);
            // Im Container speichern
            $binary .= $tmp_bin . ' ';
        }
        $binary = trim($binary);
        // Buffer für Bild anlegen
        $image = @imagecreatetruecolor($width, $height);
        if($image !== false) {
            // Größe der Binärdaten
            $binsize = strlen($binary);
            // Framenummer
            $frame = 0;
            // Position des Bits bzw. Pixels im Bild
            $top  = 0;
            $left = 0;
            // Bits durchlaufen
            for($i = 0; $i <= $binsize; $i++) {
                $bit = $binary{$i};
                // Farbwert festlegen
                switch($bit) {
                    // Schwarz für 0
                    case '0':
                        $rgb = imagecolorallocate($image, 0, 0, 0);
                        break;
                    case '1':
                    // Weis für 1
                        $rgb = imagecolorallocate($image, 255, 255, 255);
                        break;
                    case ' ':
                    // Rot als Trennungszeichen
                        $rgb = imagecolorallocate($image, 255, 0, 0);
                        break;
                }
                // Daten in Buffer zeichnen
                imagefilledrectangle($image, $left, $top, ($left + $size), ($top + $size), $rgb);
                // Position für nächsten Pixel aktualisieren
                if(($left + $size) <= ($width - $size)) {
                    // ... horizontal, falls gegügend Platz nach rechts ist
                    $left += $size;
                }
                elseif(($top + $size) <= ($height - $size)) {
                    // ... vertikal, falls genügend Platz nach unten ist
                    $left = 0;
                    $top += $size;
                }
                else {
                    // ... Ausgabe des Frames, falls voll
                    imagegif($image, $output . 'output_' . $frame . '.gif');
                    // Zähler "frame" hochzählen
                    $frame++;
                    // Zurücksetzen der Position
                    $left = 0;
                    $top = 0;
                    // Neues Frame erzeugen
                    $image = @imagecreatetruecolor($width, $height);
                }
            }
            imagegif($image, $output . 'output_' . $frame . '.gif');
            return true;
        }
    }
    return false;
}

if(bin2img('test.exe', 'output/')) {
    echo 'OK';
}
else {
    echo 'Error';
}
?>
</pre>

PHP ist für die Prototyp-Entwicklung unschlagbar

Auf alle Fälle ist das Ergebnis sehr interessant. Ich habe mal ein selbstextrahierendes Archiv mit WinZip erstellt, dass eine Textdatei mit dem Inhalt "Hallo Welt!" beinhaltet. Das Archiv ist etwa 97 Kilobyte groß. Es wurden 14 Frames (GIFs) mit einer Gesamtgröße von 126 Kilobyte erstellt. Momentan werden die Bits je nach Zustand in Schwarz und Weis dargestellt. Als Bytetrenner dient ein roter Pixel. Gelesen wird zeilenweise von oben nach rechts. Wer sich die Frames mal anschauen möchte, kann sie sich HIER bei rapidshare.com herunterladen.

Morgen versuche ich, das Script anzupassen. Ich möchte pro RGB-Wert jedes Pixels 3 Bit speichern. Dadurch werden die Frames bunter. Mal gucken, wie das aussieht. Theoretisch müssten wir dann 4-5 Frames haben, da wir ja so das dreifache an Daten speichern können...

Kannst du aus diesen Bildern mal ein Video machen und bei YouTube hochladen bzw. ein runterkombrimiertes Video erstellen und bei Rapidshare hochladen? Hab nämlich keine Video-Tools und öchte mal die Qualität sehen

 

[peter9876]

Nein ich mein die zip dateien nicht als anhang sondern das man die dateien nach als zip in das video einbaut. So ein archiv auch ohne probleme auf die richtige datengröße für ein frame gebracht werden, so fallen die teilungsvorgänge für das programm schon mal weg und der typ der nach der dekodierung rauskommt ist auch sicher.
@Karl Nickel das mit dem ton ist gar keine schlechte idee. Man könnte wieder mit 3 Tönen arbeiten (z.B. 50 Hertz für 0 220 Hertz für 1 und 400 Hertz für trennungszeichen). Ich weis leider nicht ob das in php realisierbar ist in c oder c++ auf jeden fall (wenn ich in den nächsten Tagen mal zeit hab versuch ich ein entsprechendes programm zu entwerfen das informationen in töne umwandelt und umgekehrt)

 

[NeWsOfTzzz]

Hmm hab ich auch schon daran gedacht, dass wir auf der Audiospur Töne speichern können.. das wäre dann das gleiche Prinzip, wie bei DSL Daten übertragen werden, könnte man sich überlegen, ob man ein bisschen was von der Technik abkupfert ^^

 

[Karl Nickel]

@peter
Welche Daten (ZIP, EXE, etc.) in die Frames geladen werden, spielt keine Rolle. Die Binärdaten werden in Pixelsalat umgewandelt. BTW verwende ich PHP nur zum Testen. Für ein richtiges Programm sollten wir natürlich eine Sprache verwenden, die EXE-Dateien auspucken kann Mein Favorit wäre PureBasic, da das nicht zu viel Overload hat wie zum Beispiel C++. Und man kann die Anwendungen auf Mac und Linux portieren

@all
Die Frames sehen dann etwa so aus:

Alle Frames meine gezipten "Hallo Welt.txt" könnt ihr HIER herunterladen.

Ich glaube, den Ton können wir vorerst links liegen lassen. Denn die Frames verbrauchen mehr Speicherplatz, desto mehr Daten man in ihnen verstaut. Folglich wird auch das Video größer. Würden wir nun auch noch eine Tonspur ins Video einbauen, könnte es zu groß werden. Wir dürfen ja die 100MB Uploadbegrenzung von YouTube nicht überschreiten. Eigentlich können wir nicht mehr als 80-90 Megabyte an Daten im Video unterbringen. Beziehungsweise kommt es auch darauf an, wie weit die Kombrimierung unseren Pixelsalat kaputt macht. 1x1 Pixel geht nicht, dass sehe ich mittlerweile auch ein, habs gestern abend noch ausprobiert. Mit viel Tolleranz kann man die Daten vielleicht noch auslesen, aber gerade die roten Begrenzungspixel verwaschen total. Vielleicht reicht es schon, wenn man statt rote graue Farben verwendet ... pro Bit werden wir dennoch 2x2 oder sogar 3x3 Pixel verwenden müssen...

 

[NeWsOfTzzz]

Joa iwürde mich sehr interessieren, welches Format du jetzt (1*1 oder 2*2 oder 3*3) du in den GIFs verwendest, da du feststellen wirst, dass alle übergänge durch die komprimierung sehr verschoben sind etc.
Wenn das Projekt dann sag ich mal in die Gänge kommt, können wir uns auch mal überlegen ein SVN Ordner auf Sourceforge anzulegen..
PS: Wofür brauchst du eigentliche die roten trennpixel??

 

[Karl Nickel]

Festgestellt hab ich's ja schon Welches Format wir dann letztendlich nehmen, müssen wir über Try'n Error herausfinden. Oder wir machen das, wie in der Prototyp-Funktion auch, variabel. Das heißt, der Benutzer entscheidet, welches Format er haben möchte. Macht IMHO mehr Sinn, da es immer darauf ankommt, wie hoch die Komprimierung des Videos ist.

Die roten Trennpixel brauchen wir, um die Bytes voneinander zu trennen. Man kann nämlich nicht einfach sagen, ein Byte = 8 Bit. Das Script oben wandelt die Binärdaten zunächst in ASCII um, um sie mit normalen Textverarbeitungsfunktionen bearbeiten zu können. Jedes ASCII-Byte besteht aus bis zu 7 Bit. Zum Beispiel 1101, 111001 oder 11011011. Um diese Bits nun eindeutig einem Byte zuordnen zu können, benötigen wir eine Trennung zwischen den Bytes bzw. den Bit-Aneinanderreihungen. Und dafür brauchen wir den roten Pixel. Ansonsten hätten wir eine rießige Binärzahl aus lauter 1en und 0en, die nicht in ihre Ursprungsdaten zurückgewandelt werden könnte...

 

[NeWsOfTzzz]

Natürlich kann man sagen, dass ein Byte aus 8 Bit besteht
Und ein ASCII-Byte besteht aus bis zu 8! Bit.
Und egal welche Datei du aufmachst, du wirst feststellen, dass auch hier ein Byte aus 8 Bit besteht, auch in Textdateien...
Und man braucht auch keine Trennpixel für die Rückverarbeitung, da das Programm ja sequenziell arbeitet.. sagen wir mal Blockgröße 4 dann wäre von 0-3 das erste Bit, von 4-7 das zweite etc. und das erste Byte wäre halt von 0-31, die Bytes würde er dann sequenziell in eine Datei einfügen..

 

[Karl Nickel]

Nö, ASCII-Byte besteht aus bis zu 7 Bit. Guck bei Wikipedia nach, wenn du's mir nicht glaubst Und selbst wenn es aus 8 Bits bestehen würde, das Schlüsselwörtchen sind nicht 7 oder 8 Bit sondern bis zu. Daher kann man die Daten nicht einfach Blockweise auslesen, weil ein ASCII-Byte nicht exakt 7 Bit entspricht, sondern bis zu 7 Bit. Wenn du oben im Script dir mal die Binärdaten ("print_r($binary)") ausgeben lässt, siehst du die Problematik. Du bekommst dann in etwa so eine Ausgabe:

1100
10111
10
1110010
11100
11100
11100
1100011

Jede dieser Zeilen repräsentiert ein einziges ASCII-Byte. Und wie man sehen kann, haben diese Bytes nicht die exakt gleiche Länge. Daher ist ein blockweises Auslesen der Daten unmöglich - man brauch ein Trennungszeichen. Wenn wir das nicht hätten, wären die Bytes nicht mehr getrennt und wir würden sowas einlesen:

1100101111011100101110011100111001100011

... eine riesige Binärzahl - aber kein Byte