Warez in YouTube Videos Implementieren.

[dexter]

Mit seinem Proof of Concept sagt er genau das nicht.

Ich habs tatsächlich nur so überflogen, das Genuschel nervt. Und was ich mit meinen bescheidenen Enlischkenntnissen so verstanden habe, war recht zusammenhanglos. Irgendwann sagt er sinngemäss, dass, das "9GB/Minute" wären (bei einer Textdatei...), da bin ich dann ganz ausgestiegen.
Und nochmal: was hab ich übersehen? Was inhaltlich(!) ausser "geht nicht" kann ich dem Video entnehmen?

 

[Flip]

Es sagt, dass ein durchschnittliches unkomprimiertes Video 9GB/Minute hat. Das ist natürlich zu viel, weswegen komprimiert werden sollte.
Aber Videokompression zerstört das File, wenn man ein Pixel für ein Bit benutzt. Er fand raus, dass das schon mind. 4x4 Pixel für ein Bit sein müssen, um das heil da durch zu bekommen. Das bedeutet aber den Faktor 16.

Dass es geht, zeigt er ja. Aber insgesamt kommt er auf einen Faktor von 20, den das Ergebnis größer ist, als der Payload.

Nimm mal an, Du hast ein Hörbuch von 500 MB und musst dafür ein Video von 10 GB auf YT hochladen. Und jemand anderes wieder runter.

Er sagt also nicht, geht nicht, sonder es geht, aber es ist halt absolut unpraktisch.

 

[dexter]

Das ist doch mal 'ne Ansage, womit man in einem Diskussionsforum(!) was anfangen kann.

Aber
9GB/Minute ohne da jetzt hinterherzurecherchieren, nehmen wir mal als gegeben an, das betrifft aber ein Video mit zig Millionen Farben/derber Auflösung, wenn ich dann aber 4px hernehme pro Bit und eine kleingehaltene Farbpalette, wo am Ende egal ist ob das Bit #f60 oder #f66 hat, und/oder nur 3 oder 5px gross ist, dann bekomme ich (auch durch Videokompression) ein recht schmales Video bei raus.
Oder nicht? Und wenn nicht, warum nicht?

Edit: ok, 4x4 Pixel=16, ändert inhaltlich aber erstmal nix.
Nochma Edit: 16px einfarbig entsprechen bei einem Format 1000px*1000Px ca. 7,6MB/Minute, wenn ich 16 Farben nähme, wären wir schon bei einem Faktor - ääh - 16 :P
Herrje, ich editier nu ersma nix mehr....
Grad etwas eilig, sollte ich einen derben Rechenfehler haben nicht gleich ausrasten, kuck später nochma rein.

 

[dexter]

Ok, hatte einen Rechenfehler, weiter oben im Thread war ich näher dran, dafür anderer Fehler

Mein Rechenweg zur Wahrheitsfindung mit willkürlich vereinfachten Daten zum besseren Rechnen und besserem Nachvollziehen (oder besserem Rechenfehler finden...):

Szenario 1
1 Bild/s
Video=1000X1000=1Mio Pixel
1Mio Pixel /16 Pixel * 16 Farben = 1Mio Bit
1Mio Bit / 8 / 1024 /1024 = 0,2MB/s * 60 = 7,15MB/Minute reine input/output-Daten ohne Komprimierung.

Szenario 2
Wenn man da solang an verschiedenen Stellschrauben dreht; bspw. mehr als ein Bild/s, "normale" Auflösung, soviele Farben, wie sich da zerstörungsfrei reinpressen lässt, dann sollte da einiges zusammenkommen.

Und dann noch die Videokompression oben auf...

PNG-Kompression (gerade getestet) macht auf "Szenario 1" 50kB pro Bild[1] mit 0,2MB Inhalt. Das wäre ein Faktor 40. Ja, PNG ist kein MPEG&Co, einfach nur mal paar Zahlen zum Spielen.

[1] ich hab das Hubble-Foto vom Krabbennebel genommen, das ist m.E. eine recht homogen-inhomogene Vorlage.

P.s. wegen dem PNG, falls hier irgendein Dunning-Kruger-Spezi auftaucht; nein, ich habe wirklich den Krabbennebel auf 4x4Pixel/Pixel*16Farben*1Mio Pixel reduziert.
Pps.: für die Cloogshicer, die das Thema nicht interessiert: ja bei den Einheitenbezeichnern habe ich zum besseren Verständnis Otto-normal-Standardbezeichnungen hergenommen, korrekterweise müsste da MiB und KiB usw. stehen...

 

[Flip]

1Mio Bit / 8 / 1024 /1024

Sry. Ich verstehe gerade nicht, was Du da rechnest.

 

[dexter]

Ich rechne Bit in Megabyte um.

 

[drfuture]

Bildkompremierung funktioniert über das weglassen von Details / zusammenfassen gleicher Farbbereiche mit für das menschliche Auge minimaler Veränderung >> Nur blöd wenn man damit Informationen transportieren möchte.
Videokompremierung funktioniert in dem Farbwolken (Objekte) die sich durch die Bilder bewegen nur einmal abgelegt werden und deren Bewegung durch das Bild über Vektoren repräsentiert wird >> fällt quasie weg wenn man den Film mit rauschen / Daten füllt.
1 Bit Pro Kachel stimmt auch nur, wenn man Schwarz / Weiß nimmt für farbige Punkte sind sonst je nach Farbraum z.B. 24bit Speicherplatz / Pixel notwendig, das heißt man bekommt zwar mehr Variationsmöglichkeiten aber der Speicherbedarf steigt ebenso.
Da in das Bild zusätzliche Fehlerkorrektur-Pixel eingebaut werden müssten um die Komprimierungsartefakte auszubügeln, die man bei Youtube und Co. nicht beeinflusse kann, kommt unterm Strich einfach eine riesen Datenmenge für wenig Nutzdaten raus.

 

[dexter]

je nach Farbraum z.B. 24bit Speicherplatz / Pixel notwendig, das heißt man bekommt zwar mehr Variationsmöglichkeiten aber der Speicherbedarf steigt ebenso.

24bit möchte man bei dem Szenario eher vermeiden eben wegen der Kompression. Ich vermute 256 Farben ist die absolute Kotzgrenze wo man ohne nennenswerte Artefakte durch die Kompression kommt.

 

[drfuture]

ich meinte pro Farbkanal 8bit (256 Farben) = 24bit Platzbedarf und ~16Mio Farben, was sicher zu viel ist.
Klar kann man das auf z.B. 4bit / Kanal halbieren Das sind dann 16 Farbabstufungen pro Kanal und in Summe 4096.
Nun bleibt ein Video mit 4bit /Kanal beim Upload nur kein Video mit 4bit / Kanal:

Quelle google (youtube)

Hinweis: Zur Vermeidung von Banding konvertiert YouTube Grundfarben, die eine hohe Bit-Tiefe erfordern (ohne Verwendung einer unterstützten HDR-Transferfunktion). So wird beispielsweise BT.2020 zu BT.709 (8-Bit) konvertiert, d. h., dass ein vollständiger Farbraum in einen eingeschränkten Farbraum umgewandelt wird.
Achtung: Die RGB-Farbmatrix wird für Uploads auf YouTube nicht empfohlen. Wird sie dennoch verwendet, setzt YouTube die Farbmatrix vor der Standardisierung auf nicht spezifiziert. Die Farbmatrix wird dann während der Standardisierung mithilfe der Grundfarben ausgewählt. sRGB-TRC wird zu BT.709 TRC umgewandelt. Grundfarben/Matrix/TRC werden neu als BT.709 getaggt, wenn sie durch den FFmpeg-Filter zur Umwandlung von Farbräumen nicht unterstützt werden.

 

[bazookajoe]

Das Video "Ist unwirtschaftlich, weil es so ist" ist etwas dürftig, und schöpft nicht wirklich die Möglichkeiten aus.

Wann man z.b. ein 1920x1080 Bild auf 4x4 Pixel aufteilt, macht das 518.400 Blöcke (Bits) welche umgerechnet 64.800 Byte = 63 KB entspricht.
Bei dieser Blockgröße sollte es auch eine brauchbare Videokompression geben.

Nun könnte man z.b. mit dem Farbraum spielen und z.b. bei 16 Farben die Pixel überlagern.
Somit kann man die 63KB x 16 verwenden, was schon 1 MB entspricht.

Das ganze sollte durch die großen Blöcke und wenigen Farben ziemlich Fehlerfrei auch Kompressionen überleben.
Nun könnte man noch mit den FPS Spielen und bei einem einfachen Video mit 30 FPS dort auch noch mehrere Bilder unterbringen.

Ich sehe mich leider nicht in der Lage, so etwas zu Programmieren, war aber auch nur ein Gedankenspiel der Möglichkeiten.
Einen schon erwähnten "dauert ewig" zum Verstecken und Herausziehen sollte irrelevant sein.
Und auch die Dateigröße würde sich je nach Einstellungen und Blockgröße auch noch in Grenzen halten.
Da sich durch eine Blockgröße von 4x4 Pixeln und der Wahrscheinlichkeit gleicher folgender Bits die Wiederholungen steigen und somit eine bessere Videokompression erreicht werden kann.

 

[drfuture]

129600 Blöcke wären das > 16200 byte = 15KB * 30 FPS = 450kb/s bei schwarz / weiß an maximaler Nutzlast.
Die Punkte Farbig zu machen bringt nur etwas, wenn man Bit-Sequencen einer Farbe zuweisen kann und diese Sequencen auch in den zu übertragenden Daten vorkommen. Sonst sind die Daten nunmal 0 und 1 also schwarz und weiß und nicht grün für 4. Das heißt, damit wir treffer haben muss der Bereich an Farben recht groß sein > wird dann aber ungenau bei der Komprimierung.

Die Videos auf Youtube haben wie oben beschrieben aber so oder so mind. 10bit / Kanal (*3) und damit bei 1920x1080 Auflösung und 30FPS erst einmal 220MB Rohdaten pro Sekunde!
Nun lassen sich durch die 4x4px Pixelblöcke definitiv davon Speicherplatz einsparen aber wenn h.264 das optimal umgesetzt bekommt und wir nur mit einer Auflösung 480x270 pixel rechnen wären wir immer noch bei ~100mb/s.
Angenommen die 10bit Farbpalette wird komplett fehlerfrei auf RGB Schwarz und RGB Weiß = 255,255,255 | 000,000,000 reduziert sind wir bei 3byte / Pixel * 480 x 270 = ~11MB /s + Strukturinformationen da nun noch irgendwie gespeichert werden muss wo welcher dieser komprimierten Blöcke im Bild zu finden ist.
Das heißt wenn wir die 4x4px Matrix + Farben ohne Fehler und Verluste komprimiert abspeichern haben wir immer noch ca. 11MB/s bei Vollbildern ohne das die Informationen weiter verändert werden bzw. durch Mustererkennung der sich verändernden Daten.

Binär-Informationen von bereits komprimierten Daten (Ein Video, ein RAR etc.) wiederholen sich dabei nicht wirklich - sonst könnte man sie ohne weiteres noch weiter komprimieren. Aufgabe der Komprimierung zuvor ist ja schon möglichst selten "gleiches" zu speichern.
Das heißt heiß der letzte Punkt "Die Wahrscheinlichkeit gleicher folgender Bits steigt" fällt weg.

Und von "Es ist unwirtschaftlich weil es so ist" war mein Beitrag auch schon zuvor weit entfernt.

So etwas könnte wirtschaftlich sein, wenn man alle Komponenten im Griff hat und eine perfekte Videoablage für den fall der Datenübertragung entwickelt.
Nur a) hat man Youtube und das was sie mit den Daten machen eben nicht im Griff
und b) wäre man dann am Ende bei einem Filehoster der die Datei unverändert ablegt.... ooops

 

[dexter]

Binär-Informationen von bereits komprimierten Daten (Ein Video, ein RAR etc.) wiederholen sich dabei nicht wirklich - sonst könnte man sie ohne weiteres noch weiter komprimieren.

Ja, und nein. Räumlich sieht es da eher schlecht aus, aber - wir reden von Videos - zeitlich sollte sich da schon einiges überlappen (aka komprimieren).

Und von "Es ist unwirtschaftlich weil es so ist" war mein Beitrag auch schon zuvor weit entfernt.

So etwas könnte wirtschaftlich sein, wenn man alle Komponenten im Griff hat und eine perfekte Videoablage für den fall der Datenübertragung entwickelt.

Sehe ich auch so.

 

[bazookajoe]

Die Punkte Farbig zu machen bringt nur etwas, wenn man Bit-Sequencen einer Farbe zuweisen kann und diese Sequencen auch in den zu übertragenden Daten vorkommen. Sonst sind die Daten nunmal 0 und 1 also schwarz und weiß und nicht grün für 4

Ich meinte ja die Farben Überlagern.
So kann man z.b. einfach 8 Bit mit 8 Pixelblöcken übereinander legen. Als Beispiel in 3 Schichten mit einer Einfachen RGB Lösung.
z.b.

Wert 1 = 60	0	0	1	1	1	1	0	0
Wert 2 = 160	1	0	1	0	0	0	0	0
Wert 3 = 210	1	1	0	1	0	0	1	0
RGB Wert R,G,B	0,255,255	0,0,255	255,255,0	255,0,255	255,0,0	255,0,0	0,0,255	0,0,0

Dadurch kann man die 3 Zahlenwerte 60,160 und 210 auf 8 Pixelblöcken mit 3 verschiedenen Farben überlagern.
Dazu sollte dann auch beim Decodieren die Bitwerte entsprechend ausgelesen werden.
Also nicht einfach "Block Da = 1" sondern "BLOCK Rot=1 " für alle Farben.

Binär-Informationen von bereits komprimierten Daten (Ein Video, ein RAR etc.) wiederholen sich dabei nicht wirklich - sonst könnte man sie ohne weiteres noch weiter komprimieren. Aufgabe der Komprimierung zuvor ist ja schon möglichst selten "gleiches" zu speichern.
Das heißt heiß der letzte Punkt "Die Wahrscheinlichkeit gleicher folgender Bits steigt" fällt weg.

Anhand der Tabelle oben versteht man eher, dass eine weitere Bilderkomprimierung für das Video weiterhin möglich ist.
Da es ja nicht darum geht, eine RAR Datei weiter zu komprimieren, sondern die Pixelblöcke, der der RAR Datei entsprechen.
Dabei werden weiterhin viele Blöcke identisch sein und sich bei einer Videokomprimierung auch komprimieren lassen.

So etwas könnte wirtschaftlich sein, wenn man alle Komponenten im Griff hat und eine perfekte Videoablage für den fall der Datenübertragung entwickelt.
Nur a) hat man Youtube und das was sie mit den Daten machen eben nicht im Griff
und b) wäre man dann am Ende bei einem Filehoster der die Datei unverändert ablegt.... ooops

Die Wirtschaftlichkeit nimmt irgendwann mit der Dateigröße ein Ende, das ist schon klar.
Aber, solange man genügend Daten im Video unter bekommt, z.b. durch mehrere Lagen und Unterteilung der Farben z.b. Farbwerte einer Farbe 1-128 und 129-255 dadurch von einer auf 2 Lagen aufteilen und direkt einen Wert mehr speichern zu können.

Videoportale gibt es viele, da wären z.b. Youtube, Vimeo, Dailymotion, twitch, tiktok und noch einige andere.
Zusätzlich gibt es viele ab 18 Portale, die ebenfalls Videos hosten können.
Je nach Portal kann man auch Videos in 4K @60FPS ablegen, was dann der Datenspeicher mit viel Speicher ist.

Unverändert wird die Datei dort nicht abgelegt.
Der Unterschied ist einfach, dass man Daten vor den Augen der anderen versteckt auf frei zugänglichen Plattformen ablegt.
Und schon gar nicht unverändert.

Sicher werden die Anbieter irgendwann merken, worum es sich bei den Videos handelt, aber bis dahin vergeht Zeit.
Zeit, die Normale Filehoster haben, bis Sie Geschlossen werden, was also keinen Unterschied macht.

Zusätzlich könnte man versuchen, ein schon vorhandenes Video verwenden, um die Farbpixel in einem existierenden Bild zu verändern.
Als Beispiel in der Tabelle oben, würde man einfach die bereits vorhandenen Werte aus dem Existieren Videobild stehen lassen, und nur einen Teil der Farben verändern.
So könnte man das Video als solches noch erkennen und würde je nach Anwendung nur ein Flackern einer Farbe erkennen.

 

[GoPro]

Full HD sind 1280x720 (Bei YT würde ich hier die Grenze sehen)
Macht bei Blöcken 4x4 57.6KB, die man speichern könnte. png haben 124KB

Ich habe mal etwas getestet.und 60 Mocks erstellt. Daraus habe ich ein Video gemacht 30 fps mit einem der Bilder/frame. Insgesamt 600 Bilder, also 20s.
Darin sollte man dann 34,56MB Nutzlast haben können.

Gerendert kamen 315MB raus.Youtube dampft das noch ein, kommen wir auf 45,761 MB.

Wären dann 11% oder 75%.

Aber die Kompression von YT ist Verlustbehaftet, so dass die Blöcke in der Größe vlt schwierig sind.
Und das bei S/W.(Könnte gehen, wenn man etwas fuzzy abfragt, nicht auf exakte Werte)

Spoiler: Bild

An Farben mag ich da nicht denken, schon gar nicht, da exakte rgb Werte zu bekommen.

So weit ein wenig praktische Erfahrung, aber ohne Daten.

Spoiler

Original

Bild aus dem Video

Bild aus dem YT Video

 

[bazookajoe]

Wow, das YouTube das Video so extrem zerschreddert hätte ich echt nicht gedacht.

Und es gibt dabei keine Option, das Video mit weniger Verlust dort zu speichern?
Es gibt dort ja auch qualitativ hochwertige Videos.

*Edit*

Danke für den test.

 

[Zoldan]

Full HD sind 1280x720 (Bei YT würde ich hier die Grenze sehen)

Seit wann soll FullHD 1280x720 sein? Das war noch nie der Fall! FullHD sind immer noch 1920x1080! Was Du beschreibst ist immer noch "HD Ready".

 

[GoPro]

Das ist korrekt.

 

[dexter]

@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?

Nachtrag: interessanterweise hat der: https://user-images.githubuserconte...3410-7728447d-5482-41ae-a3ff-cf8446e16ab7.gif nicht son Matsch ... oder es ist ein Fake ...Edit: kein Fake, Video dazu:

 

[bazookajoe]

Ich habe mir nicht alle Kommentare des YouTube-Videos angeschaut, aber es handelt sich dabei laut Kommentar um ein ~3GB Video mit 1GB Nutzlast.
Das Video auf 720p ist absolut ohne Matsch oder grobe Fragmente.

Sollte doch entsprechend auf Youtube dann kein Problem sein, 10 GB Nutzlast auf einem 30 GB Video zu sichern.

 

[bazookajoe]

Also, ich habe es jetzt auch mal ausprobiert, und ein 2 MB MP3 auf ein 4x4 Blöcke großes Bild mit 1920x1080 Pixel verteilt.
Insgesamt 128 Bilder.

Daraus ein Video AVI 256 Farben 1920x1080 und 30fps erstellt. Und ein 250 Großes AVI bekommen.

Bei Youtube hochgeladen und mit JDownloader als HD Video wieder heruntergeladen.
Das Video hat nach dem Download nur 15MB und ist komischerweise nicht die Qualität, die ich direkt bei Youtube sehe, wenn ich HD auswähle.

Allerdings könnte man das 15MB Video auch noch verwenden, um die Ursprungsdatei wiederzubekommen, allerdings würde es mit dem Unterscheiden in Farbschichten dann nichts werden.
Das Video auf Youtube direkt sieht dagegen in Ordnung aus.

Allerdings glaube ich irgendwo einen Fehler im Programm zu haben, da ich beim Gegenrechnen der Zahlenwerte auf 8MB Nutzmaterial komme, das MP3 aber nur 2 MB hat.