Dateien über Videoanbieter wie Youtube?

  • Allgemein

  • NeWsOfTzzz
  • 4625 Aufrufe 47 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • 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!
  • 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 :D
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • 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!
  • Gibt es bei YouTube eigentlich eine Beschränkung, wie lange ein Video dauern darf? Kenne mich damit gar nicht aus :D

    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 :baeh:
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • 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 O.o
  • 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 :D

    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...

    PHP-Quellcode

    1. function encode($file = '') {
    2. if(file_exists($file)) {
    3. $pointer = fopen($file, 'rb');
    4. if($pointer !== false) {
    5. $offset = 0;
    6. $length = filesize($file);
    7. while($offset < $length) {
    8. $buffer = fread($pointer, 1);
    9. echo $buffer. "\n" . ' =byt->hex= ' . bin2hex($buffer) . "\n" .
    10. ' =hex->dec= ' . hexdec(bin2hex($buffer)) . "\n" .
    11. ' =dec->bin= ' . decbin(hexdec(bin2hex($buffer))) . "\n" .
    12. ' =bin->hex= ' . dechex(hexdec(bin2hex($buffer))) . "\n" .
    13. ' =hex->byt= ' . pack('H*', dechex(hexdec(bin2hex($buffer)))) . "\n" .
    14. "\n\n";
    15. $offset++;
    16. }
    17. fclose($pointer);
    18. return null;
    19. }
    20. }
    21. die('Encode: File not found "' . $file . '".');
    22. }
    Alles anzeigen

    ... 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:

    Quellcode

    1. H
    2. =byt->hex= 48
    3. =hex->dec= 72
    4. =dec->bin= 1001000
    5. =bin->hex= 48
    6. =hex->byt= H
    7. a
    8. =byt->hex= 61
    9. =hex->dec= 97
    10. =dec->bin= 1100001
    11. =bin->hex= 61
    12. =hex->byt= a
    13. l
    14. =byt->hex= 6c
    15. =hex->dec= 108
    16. =dec->bin= 1101100
    17. =bin->hex= 6c
    18. =hex->byt= l
    19. l
    20. =byt->hex= 6c
    21. =hex->dec= 108
    22. =dec->bin= 1101100
    23. =bin->hex= 6c
    24. =hex->byt= l
    25. o
    26. =byt->hex= 6f
    27. =hex->dec= 111
    28. =dec->bin= 1101111
    29. =bin->hex= 6f
    30. =hex->byt= o
    31. =byt->hex= 20
    32. =hex->dec= 32
    33. =dec->bin= 100000
    34. =bin->hex= 20
    35. =hex->byt=
    36. W
    37. =byt->hex= 57
    38. =hex->dec= 87
    39. =dec->bin= 1010111
    40. =bin->hex= 57
    41. =hex->byt= W
    42. e
    43. =byt->hex= 65
    44. =hex->dec= 101
    45. =dec->bin= 1100101
    46. =bin->hex= 65
    47. =hex->byt= e
    48. l
    49. =byt->hex= 6c
    50. =hex->dec= 108
    51. =dec->bin= 1101100
    52. =bin->hex= 6c
    53. =hex->byt= l
    54. t
    55. =byt->hex= 74
    56. =hex->dec= 116
    57. =dec->bin= 1110100
    58. =bin->hex= 74
    59. =hex->byt= t
    60. !
    61. =byt->hex= 21
    62. =hex->dec= 33
    63. =dec->bin= 100001
    64. =bin->hex= 21
    65. =hex->byt= !
    Alles anzeigen

    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...
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • @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 :D
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • @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 :D

    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 :)
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • Karl Nickel schrieb:


    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 O.o
  • Karl Nickel schrieb:


    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.
    [COLOR="Green"]"A dream you dream alone is only a dream. A dream you dream together is reality"[/color]

    John Lennon

    [SIZE=1],,,[/SIZE][SIZE=1]*&#801;&#844;l&#801;*,,,,,,,,,,&#801;&#801; &#801;&#820;&#305;&#820;&#820;&#801; ,,,,,,,,,*&#801;&#844;l&#801;*,,,,,,,,,,*&#801;&#844;l&#801;*&#801;&#801; &#801;&#820;&#305;&#820;&#820;&#801; &#801;&#801;&#865;|&#818;&#865;&#818;&#865;&#818;&#865; &#818;&#9643;&#865;&#818; &#818;&#865;&#818;&#865;&#818;&#960;&#818;&#865;&#818;&#865; &#818;&#865;&#818;&#9643;&#818;&#865;&#818;&#865; &#818;|&#801;&#801;&#801; &#801; &#801;&#820;&#305;&#820;&#801;&#801; *&#801;&#844;l&#801;*_,,,,,,,,&#801;&#801; &#801;&#820;&#305;&#820;&#820;&#801; ,,,,,,,,*&#801;&#844;l&#801;*,,[/SIZE][SIZE=1],,,[/SIZE][SIZE=1],,,,,,&#801;&#801; &#801;&#820;&#305;&#820;&#820;&#801; ,[/SIZE][SIZE=1],,[/SIZE]
    [SIZE="1"][COLOR="Purple"]Up 1[/color][/SIZE] [SIZE="1"] [COLOR="Olive"]Up 2_The_Beatles_Red_Album[/color][/SIZE]
  • @ 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:

    PHP-Quellcode

    1. <pre>
    2. <?php
    3. //
    4. // $input
    5. // Pfad zur Datei, die umgewandelt werden soll
    6. // $output
    7. // Pfad zum Ausgabeverzeichnis
    8. // $size
    9. // Größe der Bits im Frame (1 = 1x1 Pixel, 2 = 2x2, ...)
    10. // $width
    11. // Breite des Frames
    12. // $height
    13. // Höhe des Frames
    14. //
    15. function bin2img($input, $output = '', $size = 1, $width = 320, $height = 240) {
    16. // Prüfen, ob Datei existiert und lesbar ist
    17. if((file_exists($input) && is_readable($input)) && is_dir($output)) {
    18. // Datei einlesen und nach base64 kodieren, um die Binärdaten zu erhalten
    19. $buffer = base64_encode(file_get_contents($input));
    20. // Buffer zur Weiterverarbeitung splitten
    21. $buffer = str_split($buffer);
    22. // Container für Binärdaten (Bits)
    23. $binary = null;
    24. // Buffer (Bytes) in Bits umwandeln
    25. foreach($buffer as $byte) {
    26. // Hex-Wert des Bytes ermitteln
    27. $tmp_hex = bin2hex($byte);
    28. // Umwandlung des Hex-Werts in eine Decimalzahl
    29. $tmp_dec = hexdec($tmp_hex);
    30. // Umwandlung der Decimalzahl in eine Binärzahl (Bits)
    31. $tmp_bin = decbin($tmp_dec);
    32. // Im Container speichern
    33. $binary .= $tmp_bin . ' ';
    34. }
    35. $binary = trim($binary);
    36. // Buffer für Bild anlegen
    37. $image = @imagecreatetruecolor($width, $height);
    38. if($image !== false) {
    39. // Größe der Binärdaten
    40. $binsize = strlen($binary);
    41. // Framenummer
    42. $frame = 0;
    43. // Position des Bits bzw. Pixels im Bild
    44. $top = 0;
    45. $left = 0;
    46. // Bits durchlaufen
    47. for($i = 0; $i <= $binsize; $i++) {
    48. $bit = $binary{$i};
    49. // Farbwert festlegen
    50. switch($bit) {
    51. // Schwarz für 0
    52. case '0':
    53. $rgb = imagecolorallocate($image, 0, 0, 0);
    54. break;
    55. case '1':
    56. // Weis für 1
    57. $rgb = imagecolorallocate($image, 255, 255, 255);
    58. break;
    59. case ' ':
    60. // Rot als Trennungszeichen
    61. $rgb = imagecolorallocate($image, 255, 0, 0);
    62. break;
    63. }
    64. // Daten in Buffer zeichnen
    65. imagefilledrectangle($image, $left, $top, ($left + $size), ($top + $size), $rgb);
    66. // Position für nächsten Pixel aktualisieren
    67. if(($left + $size) <= ($width - $size)) {
    68. // ... horizontal, falls gegügend Platz nach rechts ist
    69. $left += $size;
    70. }
    71. elseif(($top + $size) <= ($height - $size)) {
    72. // ... vertikal, falls genügend Platz nach unten ist
    73. $left = 0;
    74. $top += $size;
    75. }
    76. else {
    77. // ... Ausgabe des Frames, falls voll
    78. imagegif($image, $output . 'output_' . $frame . '.gif');
    79. // Zähler "frame" hochzählen
    80. $frame++;
    81. // Zurücksetzen der Position
    82. $left = 0;
    83. $top = 0;
    84. // Neues Frame erzeugen
    85. $image = @imagecreatetruecolor($width, $height);
    86. }
    87. }
    88. imagegif($image, $output . 'output_' . $frame . '.gif');
    89. return true;
    90. }
    91. }
    92. return false;
    93. }
    94. if(bin2img('test.exe', 'output/')) {
    95. echo 'OK';
    96. }
    97. else {
    98. echo 'Error';
    99. }
    100. ?>
    101. </pre>
    Alles anzeigen

    PHP ist für die Prototyp-Entwicklung unschlagbar :D

    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 ;) :D
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • 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)
    Wenn du zum weibe gehst nimm die Peitsche mit (Nietzsche)
  • @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 :D 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...
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • 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??
  • Festgestellt hab ich's ja schon :D 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...
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • Natürlich kann man sagen, dass ein Byte aus 8 Bit besteht O.o
    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..
  • 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:

    Quellcode

    1. 1100
    2. 10111
    3. 10
    4. 1110010
    5. 11100
    6. 11100
    7. 11100
    8. 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:

    Quellcode

    1. 1100101111011100101110011100111001100011

    ... eine riesige Binärzahl - aber kein Byte :)
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • Nein, PHP arbeitet korrekt - bei Binärzahlen gibt es einfach keine führenden Nullen :D

    Ich wandel 1 Byte in einen Hex-Wert, den dann zu einer Dualzahl und die in einer Binärzahl um, um an die Bits zu gelangen. Natürlich könnte ich "kleine" Bytes, die nur weniger als 7 Bits Platz brauchen, mit "0-Bits" auffüllen (0000010). Das macht aber bei viel Daten keinen Sinn, da jedes Byte exakt 7 Bits oder 7 Pixel Platz bräuchte. Ohne "Auffüllen" aber nur 2 Bits oder 2 Pixel plus ein Pixel zur Trennung ;)
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • DAs mit den tönen ist technisch leicht realisierbar (zumindest in c++ da eine entsprechende funktion in der WinAPI vorhanden ist BOOL Beep (DWORD dwFreq, DWORD dwDuration); ) so können nicht ganz so viele daten gesüeichert werden wie in den frames aber der platz wird besser ausgenuzt (es kann ja sein das wir es schaffen das die 10 minuten bilder keine 100mb haben). Ich werde am Wochenende mal ein entsprechendes Programm schreiben
    Edit: Wohl doch nciht so das wahre hab grad nachgerechnet mehr als 2mb wird das kaum geben. Da ich mich trotzdem gern an diesem projekt beteiligen würde würde ich es gern in c++ (habe WinAPI kenntnisse) schreiben sobald es fertig ist (hab jezt schon seit 2 Jahren kein projekt mehr gehabt)
    Wenn du zum weibe gehst nimm die Peitsche mit (Nietzsche)
  • Dich hindert niemand daran, einen Prototypen zu basteln ;) Wir müssen erst mal schauen, wie man das am besten realisieren kann und ob sich das überhaupt lohnt. Welche Sprache du für einen Prototypen verwendest, ist wurscht. Erst bei einem richtigen Programm sollten wir uns auf eine Plattform einigen...

    BTW die API-Funktion beep() sorgt nur dafür, dass der PC-Speaker biept. Mit der Funktion kann man IMHO keine Tonspur erzeugen, die man anschließend in ein Video einbinden könnte ;)

    Und ihr solltet beachten, dass sich die Daten sich nicht ins "Nichts" auflösen, sobald sie in eine Grafik oder in eine Tonspur umgewandelt werden. Hundert Megabyte bleiben hundert Megabyte. Sehr gut zu sehen bei meinen Frames des Test-Archives. 100KB Daten verteilen sich auf 120KB GIF-Dateien. Eine Komprimierung der Daten findet bei der Umwandlung dieser nicht statt. Im Gegenteil, ein Bit pro Pixel ist totale Verschwendung, wenn man bedenkt, dass ein Pixel mit den Farbinformationen über 3 Byte beansprucht, sofern man ein verlustfreies Grafikformat wählt :D

    Ich selbst werde am Wochenende mal meine Testframes bei YouTube hochladen. Mal schauen, was die Kombrimierung davon übrig lässt bzw. wieviel Speicher in einem Video zur Verfügung steht, wenn man ein Raster von 2x2 oder 3x3 Pixeln verwendet. Das Umwandeln der Daten funktioniert ja, jetzt müssen wir nur noch beweisen, dass das Zurückholen der Daten auch möglich ist und vor allem effektiv ist - danach kann man sich ernsthafte Gedanken über ein richtiges Programm machen :)
    "Ich habe ein einfaches Rezept, um fit zu bleiben - Ich laufe jeden Tag Amok."
    [SIZE="1"]Hildegard Knef (1925-2002), dt. Schauspielerin, Chansonsängerin und Autorin [/SIZE]
  • ich habe es mal mit der beep funktion versucht (die ausgaben werden zu einer wav datei hinzugefügt) und das mit den 100mb war so gemeint das da eine 10min. grenze drin ist und das 10min villeicht nicht 100mb sind. Was die endgültige sprache angeht denke ich das c oder c++ die beste wahl ist da das programm auch ohne großen aufwand auf linux und mac portiert werden kann
    Wenn du zum weibe gehst nimm die Peitsche mit (Nietzsche)