Warez in YouTube Videos Implementieren.

[one]

Ihr denkt falsch.

FullHD 1080p HQ HD - Länge 2:15 Minuten - aus 2009 - Größe: 1 Kilobyte(!):

Darum bekommt man gute Videos auf YT, welche sehr sehr lang sind.

Das wäre der Ansatz, wenn man sich wirklich noch/mal wieder damit beschäftigen will.

 

[bazookajoe]

Ihr denkt falsch.

FullHD 1080p HQ HD - Länge 2:15 Minuten - aus 2009 - Größe: 1 Kilobyte(!):

Darum bekommt man gute Videos auf YT, welche sehr sehr lang sind.

Das wäre der Ansatz, wenn man sich wirklich noch/mal wieder damit beschäftigen will.

Was willst du uns damit sagen?

Wir sollen die Nutzlast auf Algorithmen und Prozedurale Berechnungen zerlegen und eine 1KB ausführbare Datei daraus erstellen?

Das 2:15 Minuten Video hat trotzdem ~80MB und das ist ja z.b. auch der Clou an den Farbrausch Demos.

 

[dexter]

Ihr denkt falsch.

Wen meinst Du mit "Ihr"?
Warez in YouTube Videos Implementieren. Jaja, ok, das ist 4 Mal so "fett", zeigt aber mal wieder, dass Du Fäden nicht so ganz folgen kannst.

 

[dexter]

Das 2:15 Minuten Video hat trotzdem ~80MB und das ist ja z.b. auch der Clou an den Farbrausch Demos.

Nein. Das hat nur auf YT 80MB, das original hat 1KB. Siehe auch mein Link zu 'nem "fetten" 4KB-Video.

 

[one]

Ihr habt fast verstanden, warum das mit YT nicht funktioniert. Das ist btw. das Topic. Euer Vorhaben mag zu Hause auf der NAS funktionieren, aber bei keinem Videohoster.

 

[bazookajoe]

Nein. Das hat nur auf YT 80MB, das original hat 1KB. Siehe auch mein Link zu 'nem "fetten" 4KB-Video.

Nein, das Original hat keine 1KB, weil das Original kein Video ist, sondern eine ausführbare Datei.

Wie ich oben schon geschrieben habe in meiner Frage an @one, ob es der Meinung ist, dass es funktionieren soll, dass man eine Nutzlast auf Prozedurale Berechnungen und Algorithmen zerlegen soll.
Wüsste allerdings nicht, wie lange das dauern sollte, z.b. eine 2 GB Datei auf ein Schema zu analysieren, um es dann per Algorithmus zu generieren.

Denn so werden in den Demos (wie z.b. bei Farbrausch auch) die Texturen und Musiken berechnet.

 

[dexter]

Nein, das Original hat keine 1KB, weil das Original kein Video ist, sondern eine ausführbare Datei.

Das ist Haarspalterei. Stimmt zwar, ist aber falsch und richtig gleichzeitig. Das Ergebnis auf meinem Monitor am Ende ist das Selbe.
Das eine ist eine exe und das andere ein avi/mpeg/irgendwas.
Und ja, wie ich bereits sagte; haben wir hier zuviele Themen auf einmal, und DAS wäre noch ein weiteres.

 

[dexter]

Ihr habt fast verstanden, warum das mit YT nicht funktioniert. Das ist btw. das Topic. Euer Vorhaben mag zu Hause auf der NAS funktionieren, aber bei keinem Videohoster.

Beteilige Dich am Thema, oder lass es. Bitte.

 

[bazookajoe]

Das ist Haarspalterei. Stimmt zwar, ist aber falsch und richtig gleichzeitig. Das Ergebnis auf meinem Monitor am Ende ist das Selbe.
Das eine ist eine exe und das andere ein avi/mpeg/irgendwas.

Nein, das ist keine Haarspalterei, das eine ist ein ausführbares Programm, welches zur Laufzeit die entsprechenden Daten generiert, und das andere ist ein Bildcontainer, der den Inhalt im Idealfall 1:1 speichert.

Wenn ich ein Programm schreibe, was 24 Stunden in Endlosschleife alle Farben in einer 4K Auflösung anzeigt, ist das Programm wenige KB groß.
Nun nehme ich das Video allerdings auf und speichere es ab, habe ich ein mehrere Hundert GB großes Video mit 24 Stunden Bildmaterial.

Nehmen wir ein anderes Beispiel, ich erstelle aus der Nutzlast (RAR oder was auch immer) kein Video, sondern eine Audiodatei und lade diese bei Youtube oder einem Musik hoster hoch,
dann habe ich mehrere Stunden Geräusche.
Eben das gleiche Prinzip wie eine Datasette beim C64, Fax oder AkkustikKoppler.

Das Ergebnis mag vielleicht das selbe sein, aber es geht eben darum, in einem Video eine Nutzlast zu Speichern.

 

[dexter]

Nun nehme ich das Video allerdings auf und speichere es ab, habe ich ein mehrere Hundert GB großes Video mit 24 Stunden Bildmaterial.

Das habe ich nicht bezweifelt.

Eben das gleiche Prinzip wie eine Datasette beim C64, Fax oder AkkustikKoppler.

Auch Offtopic: Erinnert mich an Zeiten,wie wir ausm Radio (!) und ausm Fernsehen (!!!) Programme "runtergeladen" haben.

 

[bazookajoe]

Auch Offtopic: Erinnert mich an Zeiten,wie wir ausm Radio (!) und ausm Fernsehen (!!!) Programme "runtergeladen" haben.

Eigentlich nicht, da beim Umwandeln der Daten in ein Audiosignal die gleiche Grundidee dahinter steht.
Ein Datensatz, völlig egal worum es dabei geht (RAR,MP4,MP3...) wird in ein Audiosignal oder Bitcode auf Bildern->Video umgewandelt und gespeichert.

Ich denke jeder hier hat schonmal den Timecode auf einem VHS Video gesehen, was im Prinzip auch nichts anderes ist.
Die Laufzeit eines Videos als Binärcode im Bild versteckt.
Dabei ist die Nutzlast in dem Video die Information über die Laufzeit des Videos.

*Edit*

Als einfaches, simples Beispiel fällt mir gerade noch der QR-Code ein.
Man nehme 200 Bilder mit QR-Codes, erstelle daraus ein Video. und speichere dieses bei Youtube.

Nun enthalten diese QR-Codes aber nicht wie allgemein üblich einen Hyperlink, sondern die Daten werden als Bytes gelesen und gespeichert.
Und am Ende kommt z.b. ein MP3 raus.

 

[one]

Die Quintessenz ist, dass es nicht funktionieren wird. Und das ist das TOPIC! YT wird einen Scheiß tun und sowas dulden. Alleine die Bearbeitung des Videos nach dem Hochladen wird dem ganzen einen Riegel vorschieben. Die machen das sicher nicht um Speicherplatz zu sparen. Problem ist: da sitzen keine dummen Programmierer.

In der lokalen Praxis ist das alles möglich. Ein Videohoster hat das schneller unterbunden als das Video hochgeladen ist. Was btw. auch deren rechtliche Aufgabe ist.

 

[GoPro]

@GoPro Du hast übrigens im Originalvideo schon dezent Artefakte drin, wird aber nicht den YT-matsch erklären.

Wieviel Zeit hast Du da gebraucht? Ich bin wenig optimistisch, aber magst Du mal 2x8-Pixel (oder zusätzlich noch 8x2?) testen, ob da der selbe Matsch rumkommt?

Das Rendern hat 52s gedauert. Das geht auf einem für Videobearbeitung geeigneten PC sicher schneller.
Das ist aber nicht unbedingt langsamer als anderer Inhalt. Ich revidiere meine Meinung von oben mit den ewig und 3 Tagen.

Aber der Inhalt ist wohl der Grund für den "YT-matsch". Youtube wird da keine Kompression durch Zusammenfassung von Gleichheiten durchführen, sondern das Video durch das Senken der Bitrate erreichen. Das senkt bei der Art des Videos die Qualität deutlich.

Erklärung:

 

[bazookajoe]

Die Quintessenz ist, dass es nicht funktionieren wird. Und das ist das TOPIC! YT wird einen Scheiß tun und sowas dulden. Alleine die Bearbeitung des Videos nach dem Hochladen wird dem ganzen einen Riegel vorschieben. Die machen das sicher nicht um Speicherplatz zu sparen. Problem ist: da sitzen keine dummen Programmierer.

In der lokalen Praxis ist das alles möglich. Ein Videohoster hat das schneller unterbunden als das Video hochgeladen ist. Was btw. auch deren rechtliche Aufgabe ist.

Deine Quintessenz ist Quatsch.
Es funktioniert nicht nur in der Theorie, sondern auch in der Praxis.
Und nur weil du es als Quatsch empfindest, heißt nicht, dass es nicht funktioniert.

Ich habe mein Video von gestern erneut hochgeladen. Bei der Einstellung HD (1080) kann man im Vollbild ziemlich gut sehen, dass die Pixel ohne Probleme zu erkennen sind, und man die Daten auch entsprechend zurückholen kann.
Und auch wenn ich das Video jetzt herunterlade, sind die Pixelblöcke ohne Matsch erkennbar.

Und falls das Video hier nicht brauchbar sein sollte, einfach extern mit dem Link Zusatz "&vq=hd1080" öffnen, da dies den HD Modus erzwingt.
Also https://youtu.be/xfzh5K_xr8c&vq=hd1080

Da irgendwas mit Prozedurale Berechnungen zu vergleichen ist Quatsch.
Wie ich oben schon geschrieben habe, könnte man ebenso QR-Codes verwenden, und die sind sehr robust, was Beschädigungen angeht.

Klar wird YT so etwas nicht dulden, aber es würde ja z.b. auch die Lösung mit Farben geben, die wie ein Wasserzeichen eingeblendet werden.
Dadurch sind die Daten auf den ersten Blick nicht zu erkennen, und müssen einer Extrakontrolle unterzogen werden, um z.b. einfache Fehler in Videos oder Wasserzeichen von solchen Informationen zu unterscheiden.
Sonst würde YT jedes Video löschen oder nicht freigeben, wenn etwas "Verdächtig" ist.

YT duldet dies genauso, wie die gängigen Sharehoster die 100 Millionen RAR Files dulden.
Aber, wie ich ebenfalls schon geschrieben habe, es gibt nicht nur Youtube.

Wie ich auch schon geschrieben habe, könnte man genau so auch ein MP3 erzeugen und speichern.

 

[Zoldan]

Klar wird YT so etwas nicht dulden, aber es würde ja z.b. auch die Lösung mit Farben geben, die wie ein Wasserzeichen eingeblendet werden.
Dadurch sind die Daten auf den ersten Blick nicht zu erkennen, und müssen einer Extrakontrolle unterzogen werden, um z.b. einfache Fehler in Videos oder Wasserzeichen von solchen Informationen zu unterscheiden.

Jetzt seid ihr schon über eure "Channel Videodat" Theorien bei Steganographie angekommen. Nicht schlecht. Weiter so!

 

[bazookajoe]

Jetzt seid ihr schon über eure "Channel Videodat" Theorien bei Steganographie angekommen. Nicht schlecht. Weiter so!

Wenn man den Startbeitrag liest, hätte man erkennen können, dass Steganografie unter anderem auch eine Idee für die Sache war.
Aber, das hast du sicher gemacht, und nur vergessen hier zu erwähnen.

Ebenso könnte man auch Dateien in normalen Videos verstecken, indem man das Bild nicht Voll ausfüllt, sondern nur verschiedene Blöcke.

 

[Flip]

Informationen in laufenden Bildern ist ja ein alter Hut. Der WDR Computerclub hat bereits 1986 Software während der laufenden Sendung als Bits als schwarz/weiße Kästchen außerhalb des sichtbaren Bereiches übertragen.

Und BBC hat Teletext Anfang der 70er erfunden, der ab 1980 ausgestrahlt wurde, was ähnlich funktioniert.

Und von Steganographie ist in diesem Thread gar nicht die Rede. Bei Steganographie nutzt man aus, dass man niedrige Bits bei RGB verändern kann, ohne das das Auge das als Farbveränderung wahrnimmt, aber man die Abweichungen für Daten nutzen kann.

Wovon hier im Thread die Rede ist, die Daten explizit in die Videobilder zu schreiben.

 

[bazookajoe]

Und von Steganographie ist in diesem Thread gar nicht die Rede. Bei Steganographie nutzt man aus, dass man niedrige Bits bei RGB verändern kann, ohne das das Auge das als Farbveränderung wahrnimmt, aber man die Abweichungen für Daten nutzen kann.

Wovon hier im Thread die Rede ist, die Daten explizit in die Videobilder zu schreiben.

Hab ich doch in fast jedem meiner Beiträge hier geschrieben,
dass man damit vielleicht auch die Möglichkeit hat, die Daten im Video zu verstecken.

Schon direkt im Eingangsbeitrag.
Dazu könnte man verschiedene Möglichkeiten versuchen.

z.b. bei 30 FPS jedes 3 Bild durch ein Datenbild austauschen.
Oder eben die Funktion, in einem vorhandenen Video nur einen Farbton für die Datenblöcke zu verwenden.

Wenn man beides miteinander verbindet und z.b. nur jedes 10 Bild verwendet, nimmt der Zuschauer zwar eine Störung im Video wahr, aber muss sich dabei nichts denken.
YT wird bei der Analyse vielleicht was erkennen, wird es aber vielleicht nicht beachten, da es sich genauso gut um Wasserzeichen oder eine einfache Störung handeln könnte.

Links Normal , Rechts mit Datenblöcken, die sich nur im roten Farbton befinden.

 

[Flip]

Dazu könnte man verschiedene Möglichkeiten versuchen.

z.b. bei 30 FPS jedes 3 Bild durch ein Datenbild austauschen.

Verstecken ist etwas anderes.

 

[bazookajoe]

Verstecken ist etwas anderes.

Ok, das ist nicht wirklich unauffällig.
Dann wäre die Option über die Farben wohl die unauffälligere Lösung.

Falls ich mal die Zeit finden sollte, versuche ich mich irgendwie mal an einem Programm um sowas zu machen.