 Ja, willkommen zurück hier auf dem FemmChannel. Unser nächster Speaker ist Janik. Er hat Medientechnik studiert und sich dabei unter anderem mit Livestreaming im Internet und auch Algorithmen der Videokompression beschäftigt. Jetzt in diesem Talk möchte er uns einmal die Grundlagen der modernen Kompressions-Algorithmen erklären. To all the English-Speaking-Listeners, this talk will also be translated into the English language. For this, please open the language selection tool in the web player and select the translated stream. Und nun, viel Spaß bei diesem Talk. Hi und willkommen zu meinem Vortrag Grundlagen der Videokompression. Es sollen um die Grundlagen, also um die Berge und jeder Videokompression gehen, die eigentlich in fast allen Standards umgesetzt wird. Ganz kurz zu mir, ich bin Janik, studiere Medientechnologie an der THKöln und ich bin Entwickler bei OnCast. OnCast ist eine Alternative zu Twitch, die man selber auf seinem einen Server aufsetzen kann. Im Internet findet ihr mich ja unter den ganzen Links. Um geht es in diesem Vortrag generell die Kompression, die im Verlust behaftete Kompression von Videodateien. Wie gerade schon gesagt, sollen die Grundgedanken gehen, ohne jetzt auf eine spezielle Implementierung einzugehen. Daran hangere ich mich an den MPEG-Standards, das heißt H264, 5 und 6 und MPEG-TS1. Außerdem soll es einen kleinen Forscher auf den Kondensstandard H266 oder VVC geben. Es wird allerdings nicht jedes Detail erläutert. Wie gesagt, dieser Vortrag soll 20 Minuten gehen und er setzt damit natürlich keine 6 Monate lang Vorlesung. Ich denke, das sollte jedem klar sein. Wir fangen an mit einem kleinen Lexikon. Das ist ein Pixel. Ein Pixel besteht typischerweise aus mehreren Kanälen, z.B. Rot, Grün, Blau. Manchmal ist auch eine Alpha-Channel dabei, manchmal nicht, manchmal sind die Channels anders benannt. Außerdem gibt es dann ein Bild, einen Frame und ein Frame hat dann mehrere Pixel, die in so einem Raster angeordnet sind. Zum Beispiel, die ist ein Raster dann 4 zu 3 oder 16 zu 9 oder wenn man aus TikTok kommt, halt 9 zu 16. Wenn man dann eine Menge an Bildern oder Frames hintereinander anordnet, wird auch eine Sequenz. Das habe ich jetzt hier wie so ein Analogfilm dargestellt. Die Älteren werden sich vielleicht daran erinnern. Wofür brauchen wir eigentlich diese Kompression? Also, warum brauchen wir verlustbehaftete Kompression, wenn wir eigentlich daher von den Videos Internet stellen wollen oder Video generell aufnehmen und verarbeiten wollen? Dazu habe ich jetzt mal auf dem Rücken eines Briefungsschlages zusammengerechnet. Wir haben drei Kanäle, habe ich gerade gesagt, drei Kanäle pro Pixel, die jeweils mit 8 Bit auch so steuert werden. Zum Beispiel, das ist so eine relativ standardmäßige Anzahl. Wenn man das jetzt auf einem Full HD Bild, also 19x20x1080, hat und 25 mal diese Kunde, kommt man auf eine Bit-Ratur von 1,16 GbBit pro Sekunde und das ist einfach eine ganze Menge Holz. In der Video-Bearbeitung erscheint das vielleicht noch tragbar. Allerdings, wenn man das dann über das Internet spielt, zum Beispiel von Media-CCC runterlässt, dann bleibt das einfach zu Problemen und Telekom sagt einfach nein. Das war auch schon vorher ein Problem, bevor wir mit Full HD angefangen haben oder kleinere Videos, denn zum Beispiel so ein Kinofilm in dieser Auflösung in 90 Minuten sind 6,2 GB weit und das geht einfach nicht. Das ist einfach viel zu viel. Kurzem Vergleich, das sind 1400 DVDs mit 4,7 Gbps oder 500.000 Disketten mit 1,44 GB weit. Bevor wir uns allerdings darüber halten, wie wir das Video kleiner machen, müssen wir uns erst darüber halten, wofür wir überhaupt Video einsetzen. Also wofür nutzen wir Video und wo soll es zum Beispiel dargestellt werden. Als erstes, das ist so der klassische Anwendungsfall, haben wir Kino oder analoges Fernsehen. Dabei gibt es meistens eine Zuwertung zum Display, die ist in der Regel stabil, zum Beispiel im Kino gibt es halt pro Saal einen Festplatte, von der dieser Film geladen wird und nichts anderes. Im analogen Fernsehen gibt es halt die Leitungen, über die halt mehr Kanile geleitet werden, aber auch über die passiert nichts anderes. Das ist ein bisschen anders im Online- oder Heimtv-Bereich, wo es halt Video und Demand, Plattform wie MediaCCC oder Livestream-Plattform wie Streaming.medium.ccc gibt und da gibt es in der Regel eine instabilere Zuleitung von der Quelle zum Display, weil zum Beispiel das Internet zwischendbrückelt oder man gerade im Zug sitzt und von dort aus streamen will. Ein weiterer Anwendungsfall ist Video-Telefonie. Video-Telefonie haben wir jetzt durch die Pandemie wahrscheinlich alle kennengelernt und auch schon vorher war es einfach ein riesengroßer Sektor und um sinnvoll an einem Gespräch teilzunehmen, ist es wichtig, dass es eine mögliche geringe Latenz gibt, damit sich die Leute nicht gegenseitig ins Wort fallen und ja, das Video und das Audio vor allem gut übermittelt wird. Es ist eigentlich klar gerade durch die Pandemie, dass es nicht perfekt ist und darum ist es nicht so schlimm, dass das Video vielleicht ein bisschen brücklich ist oder einer schlechteren Qualität ist, aber Hauptsache es ist da und es wird angezeigt und es wird auch gleichzeitig mit dem Audio übertragen und auch gleichzeitig mit dem Audio dargestellt. Ein Anwendungsfall, der in der Chaosbabel wahrscheinlich nicht so verbreitet ist, auf den ich aber trotzdem kurz eingehen möchte, sind Überwachungskameras. Diese kommen meistens nicht alleine, sondern hier zum Beispiel schon zu dritt und filmen einfach 24-7 in der Gegend rum und dabei kommen unendlich große Datenmengen zusammen, obwohl meistens oder vielleicht einfach nur ein Lehrer Raum gefilmt wird und das möchten wir gut konfirmieren, denn wir wollen ja kein Kinofilm gucken, sondern wir wollen einen Zweifel sehen, da läuft jemand von A nach B oder das ist ein Gesicht von einer Person usw. Dementsprechend sind die Anwendungsfälle von der Videokompression bei einer Überwachungskamera ganz anders als beim Kinofilm. Als letzten Punkt möchte ich noch Bilderkennung und Bildgebnissesysteme anbringen. Diese werden zum Beispiel in der Medizin oder in den Industrie verwendet, um Auffälligkeiten zu analysieren und halt darzustellen und hierbei ist es dann problematisch, wenn es Vorstellung an Kompression gibt, die wichtige Inhalte verschiebt, unkenntlich macht oder irgendwie nicht darstellt, denn dann sieht man zum Beispiel einen Bruch nicht oder einen kleinen Gehirntumor usw. Nachdem wir das jetzt klärt haben, können wir weitere reden, wie funktioniert eigentlich diese Videokompression. Das Erste, woran man denkt, wenn man an Videokompression denkt, ist wahrscheinlich, dass man einfach weniger Pixel macht durch eine kleinere Auflösung und das funktioniert auch ganz gut. Wir haben hier vier grüne Pixel und vier blaue Pixel und die kompromieren wir runter auf einen grünen und einen grauen Pixel und dadurch haben wir 75% der Spanis. Wenn wir die beiden Pixel dann allerdings auf dem großen Display wieder anzeigen möchten, dann ist uns nicht so richtig klar, wie zahlen wir diese Daten jetzt an. Wir können zum Beispiel die Pixel einfach wieder aufskalieren, dann haben wir allerdings eine große Fläche, die am Ende eine scharfe Kante hat und innerhalb der Fläche halt keine Struktur. Das sieht ein bisschen aus wie beim Mal nach Zahlen und das ist vielleicht nicht das, was man haben möchte. Das Nächste wäre dann, dass wir die Pixel anteilig aus den Nachbarn berechnen. Das geht beliebig kompliziert, zum Beispiel hier über einen Linear und Gradient im RGB Raum. Allerdings gibt es dann hier so einen grauen Schleier in der Mitte, der kommt daher, dass wir im RGB Raum interpolieren. Das kann man wie gesagt auch beliebig kompliziert machen. Zum Beispiel haben wir hier auch nur zwei Stützpunkte, weil wir ein dimensionales Bild haben. Meistens gibt es allerdings ein zweidimensionales Bild und der hat dann vier Stützpunkte und so weiter. Hier gibt es noch einmal die Formel dazu, das ist einfach lineare Anteile von den zwei Bildern und von den zwei Pixel werden. Die Entwicklerinnen der Videocodex haben einige Annahmen über das Videomaterial, das sie komprimieren wollen, getroffen und wieder Mensch dieses wahrnimmt. Wenn man auf diese Annahme vertraut, kann man daraus technische Ideen ableiten und ich sage mal so, das hat bisher ganz gut funktioniert. So ein paar dieser Annahmen möchte ich jetzt auch euch vorstellen. Die erste Annahme ist, dass das menschliche Auge Helligkeitsunterschied besser darstellt als Farbunterschiede. Wenn wir es also schaffen, die Helligkeit eines Pixels von der Farbfarbe zu trennen, können wir die Farbdaten mit weniger Auflösung speichern und sparen uns dadurch breiter. Bisher haben wir uns hier eben über diesen RGB-Fahrbraum, also rot-grün-blau Fahrbraum, wieder halten. Bei diesem neuen Fahrbraum, YCBCA, gibt es dann einen eigenständigen Kanal für die Helligkeit und dann zwei für Farbaussteuerung. Die Helligkeit kann von 0 bis 1 gehen und die Fahrbaussteuerung von minus 1 bis plus 1 und daraus ergibt sich dann auf der rechten Seite dieser schrägstehende Würfel. Wenn man sowohl blau als auch rot auf dem Minimalwert einstellt, kommt man bei grün raus und das zum Beispiel auch der Grund, warum der VLC-Player das Bild bei Fehler übertragen halt grün darstellt. Also grüne Pixel bedeutet man dessen Fehler oder da hat es irgendwas nicht beim Dekodieren geklappt. Die Idee kommt ursprünglich für eine Umstellung vom analogen schwarz-weiß Fernsehen zum Farbfernsehen. Die älteren Geräte haben sich nur das bekannte schwarz-weiß Signal aus der Helligkeit gezogen, während neue Geräte halt auch das Farbsignal rausgezogen haben und das farblich halt dargestellt haben. Um diese Farbwerte nun grüber als die Helligkeit abzutasten, gibt es sogenannte Color Modes und Color Sub-Sampling oder Chroma Sub-Sampling. Die drei Verbreitest im Color Modes habe ich hier einmal hier dargestellt. Zum Start bieten immer vier Helligkeitswerte, denen dann entweder zwei, vier oder nur ein Farbwert pro rot und blau zugeordnet wird. Der verbreitetes Modus ist 420, die auf der rechten Seite, bei dem auf allen Farbwert vier Helligkeitswerte kommen. Der Modus wird im ersten M-Codec vorausgesetzt und ist erstandert und so gut wie allen anderen, ja, verlustbehaffelten Videocodecs. Wenn man sich die Anzahl der Blöcke ansieht, sieht man, dass bei 420 nur sechs Beit und bei 444 zum Beispiel zwölf Beit übertragen müssen. Und das ist gut, weil das schon wieder die Hälfte der Pixel nur noch. Die nächste Annahme ist, dass es im Bild einen Vorder- und einen Hintergrund gibt. Und daraus ergibt sich, es gibt vielleicht Bereiche, die gröber und feiner aufgelöst werden müssen und das Bild angemessen zu repräsentieren. Dazu gibt es einen Modus, der heißt Blockbildung und dazu teilt man das Bild halt mehrere Blöcke auf. JPEG, MPEG und H264 haben feste Blockgrößen und ab H265 gibt es ein Modell mit variabler Blockgröße. Das erkennt man hier rechts an der Grafik. Die Blöcke werden so lange verkleinert, bis sie keine oder noch wenig Strukturen halten. Außerdem anhand dieser Kurve erkennt man dann, dass die Struktur entlang dieses Saums genauer aufgelöst werden muss als entlang einer großen Farbfläche. An dieser Stelle wäre es total super, wenn ich etwas über dieses Kursinus-Transformation sagen könnte, aber das sprengt leider echt den Rahmen meines 20 Minuten Vortrags. Die nächste Annahme ist, dass aufeinander folgende Frames gleich oder sehr ähnlich im Bild erneut haben und dadurch können wir eigentlich nur das übertragen, was sich ändert und weniger beim Breiten nutzen. So das Prinzip heißt Differenzbilder oder Delta-Bild. Ein Delta-Bild stellt jeweils nur den Unterschied zum Verhängen Frame dar. Regenmäßig werden Keyframes, sogenannte Interframes übertragen, die ein vollständiges Bild darstellen. Dadurch wird Skipping ja möglich, also wenn du in einer Video-Datei nach vorne springst, springt der Player dann meistens nur zum nächsten Interframe und spielt das Video von dort aus ab. Eine Reihe dieser zusammengehörenden Frames, also immer ein Interframe und dann mehrere Delta- Bilder, heißt ein Group of Pictures. Es gibt die Interframes, sondern gibt noch die predicted Frames, P-Bilder und die zeigen einfach nur die Differenz an. Hier auf dem rechten Bild sieht man einmal ein Testvideo, Crowdrun heißt das, wo wir den ersten Frame, den zweiten Frame und hier die Differenz darstellen. Und wir sehen, so viel ändert sich eigentlich nicht, der Baum ist zum Beispiel komplett dargestellt und fast ohne Änderung. Und das müssen wir einfach überhaupt nicht übertragen, weil wir sagen einfach, okay für die nächsten 100 Pixel gibt es ja keine Änderung oder in diesem Blockbereich. Die nächste Annahme ist, dass eine Sequenz eine Bewegung abbildet. Wir können also zum Beispiel, wenn wir einen Block um ein Objekt haben, nur die Verschiebung dieses Objektes übertragen. Da gibt es zwei Möglichkeiten für einmal Global Motion Compensation und einmal Block-Based Motion Compensation. Und bei der Global Compensation verschiebt oder skaliert man das ganze Bild. Das ist gut bei Bewegungen, Reinsum, Raussum und so weiter. Die Technologie wird allerdings nicht mehr so häufig angewendet, da sie relativ komplex in der Inkludierung ist und im Outcome eigentlich hinter den Erwartungen zurück bleibt. Die Block-Motion Compensation arbeitet allerdings mit Blocken, die wir eben schon beschrieben hatten. Jem Block wird in einem Suchalios mit dem nächsten Frame verglichen und die Position mit der geringsten Differenz wird dann als Vektor notiert. Der frei geworden Bereich wird entweder durch eine Blockverschiebung gefüllt, also über eine weitere Blockverschiebung oder durch eine Differenzbildung aus dem letzten Bild. Das Suchalios kann auch auf Suchpixel-Abbases, also zum Beispiel auf ein Viertelpixel gehen, aber wie granoladas ist, hängt immer vom Codec ab. Ein Nachteil hat diese Bewegungskomplizierung allerdings und zwar gibt es immer Unhebenheiten an den Blockgrenzen. Das kann man dann probieren, über Differenzbildung auszugleichen, jedoch gibt es einfach manchmal Blöcke, die verschoben werden und das sieht dann komisch aus, vor allem wenn es auch einen Fehler in der Datei gibt oder einen Sprung in der DVD. So das war es mit den Annahmen, die ich vorstellen wollte. Ich möchte jetzt noch ganz kurz auf H2-6-6 oder VVC eingehen. H2-6-6 und VVC ist derselbe Standard. Der wird zusammen von der ISO und von der MPEG, also Motion Pictures Experts Group, entwickelt und die haben zwei verschiedene Nadensschirmata und darum hat der Standard zwei verschiedene Namen. H2-6-6 hat das Ziel, 50 Prozent weniger Bitrate bei gleicher subjektive Qualität gegenüber dem Vorgänger zu haben. Das heißt, das Video, das gut oder gleich gut dargestellt werden soll, so 50 Prozent weniger Traffic und Bitrate verbrauchen als bei H2-6-5. So, H2-6-5 hatte das Ziel auch und dadurch sind wir bei 75 Prozent weniger Betrate gegenüber H2-6-4. Was ändert sich jetzt? Ganz viele Dinge haben sich geändert. Ich habe jetzt einfach mal fünf rausgepickt. Das sind gar nicht fünf, das sind nur vier. Es gibt einmal eine veränderte Blockbildung. Der Helligkeitskanal kann zum Beispiel jetzt anders eingeteilt werden als der Chromatkanal, also Chroma Blau und Chroma Rot. Das ist total super, wenn du einen Kanal hast, der sich zum Beispiel in der Helligkeit nicht ändert, aber nur in der Farbe oder der sich in der Farbe nicht ändert, aber dafür in der Helligkeit total scharf. Der zweite Punkt ist, dass es virtuelle Bildgrenzen in einem Bild gibt. Das hat man aus der Realität genommen, hier von 63 Grad Videos, die halt in der Mitte so eine Kante haben, wo es einfach dadurch, dass das Video aus sechs verschiedenen Kameras zusammengestitched wird, gibt es einfach keine Überlappung und es gibt keine Verschiebung aus dem einen Bild ins nächste Bild und dadurch gibt es auch fassierte Blockgrenzen. Ein weiteres Ding ist der Pellet Mode. Gerade bei Bildschirmenvertragungen brauchen wir nicht eigentlich alle Farben. Dafür brauchen wir eigentlich eine hohe Auflösung, um zum Beispiel kleinen Text halt gut darzustellen. Auf dieser Folie haben wir hier weiß, schwarz und ein bisschen gelb. Wir brauchen allerdings nicht den kompletten RGB Farbraum oder Y oder nur Farbraum. Mit dem Pellet Mode reicht es dann, diese gegebenen Bilder auf ganz kleinen Werte zusammenzusetzen und so eine höhere Auflösung bei weniger Daten darzustellen. Sowo wird H266 jetzt verwendet? Der Standard ist seit 2020 verabschiedet und veröffentlicht. Es gibt einen V1, eines Encoders und der ist seit Mitte 2021 verfügbar. Es gibt allerdings noch keine oder nur sehr wenige Unterstützung in der gängigen Software, zum Beispiel FFM-Pack, VLC Player oder ungefähr jede Videobearbeitung Software. Dadurch dauert das einfach ein bisschen. Man kann sich allerdings zum Beispiel FFM-Pack auch selber bauen mit dem H266 Encoder drin. Ein weiterer Punkt sind die Co-Prozessoren. Eigentlich jedes Handy, jeder Laptop, jeder Computer hat ein Co-Prozessor für Videoencoderung und Videodekoderung und die gibt es auch einfach noch nicht. Das dauert jetzt einfach bis die halt so nach und nach auf den Markt kommen. Die Adoptionsphase hat zum Beispiel H265 jetzt 4, 5, 6, 7 Jahre gedauert. 2013 wurde der H265 Standard veröffentlicht und in 2017 hat iOS dann angefangen HLVC, also H265 Standard-mäßigen Videos zu verwenden. So das war es eigentlich schon mit meinem Vortrag. Ich habe im Haufen Bildquellen verwendet. Die habe ich viele aus Webseiten oder aus Papers. Ich stelle den ganzen Vortrag auch online und da könnte ich hier auf die Links drauf klicken dann. An dieser Stelle möchte ich mich für eure Aufmerksamkeit bedanken. Bei Feedback kommt gerne auf mich zu über Twitter, Filiverse oder andere Möglichkeiten, wie man mich erreichen kann. Danke fürs Zuschauen und euch noch einen sehr schönen RC3 und einen guten Übergang ins neue Jahr. Ja, vielen Dank Janik für diesen interessanten Vortrag zur Videokompression. Für Fragen steht euch Janik gleich in der RC3-World zur Verfügung. Dort werden wir eine kleine Breakout-Session halten und zwar wieder in der Femme Assembly. Also kommt gerne vorbei in die RC3-World zur Femme Assembly. Next up, um 22 Uhr geht es weiter mit einem Schema wie eine Verifikation der Stimmeauszählung bei Wahlen möglich ist und um 24 Uhr wie gewohnt die Harriet News Show. Bis dahin!