diff --git a/courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md b/courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md
index 922bf28..2dd8d58 100644
--- a/courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md
+++ b/courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md
@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -55,7 +55,7 @@ section.klausur {
     #e3f2fd 40px,
     #fff 40px,
     #fff 80px
-  );
+  ) !important;
 }
 section.aufgabe {
   background: #e3f2fd !important;
@@ -67,7 +67,6 @@ section.aufgabe footer {
 
 <!-- _class: invert -->
 <!-- _header: '' -->
-<!-- _footer: '' -->
 <!-- _backgroundColor: #000 -->
 
 ![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
@@ -78,12 +77,12 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
-
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
 ---
 
+
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -93,8 +92,28 @@ Hochschule der Medien Stuttgart
 
 <!-- _class: lead -->
 
-# Teil 1: Dateiformate
-## Bild-, Audio- & Videoformate
+# Teil 2: Bild- & Videoformate
+
+---
+
+# Warum verschiedene Dateiformate?
+
+**Ein Dateiformat definiert:**
+- Ob und wie Daten komprimiert werden
+- Welche Metadaten enthalten sind
+- Wie Daten *codiert* und *decodiert* (*Co·dec*)
+
+| Ziel | Bild | Audio | Dokument |
+|------|------|-------|----------|
+| Kleine Dateien | JPEG | MP3 | — |
+| Perfekte Qualität | PNG, RAW | FLAC | PDF |
+| Animation/Video | GIF | — | — |
+| Skalierbarkeit | SVG | — | PDF |
+
+<!--
+Dateiformate sind Kompromisse zwischen Größe, Qualität und Features.
+Die Wahl hängt vom Anwendungsfall ab.
+-->
 
 ---
 
@@ -106,28 +125,32 @@ Hochschule der Medien Stuttgart
 <!--
 Links: Hochauflösend
 Rechts: Stark komprimiert (JPEG-Artefakte sichtbar)
-Instagram-Effekt
 -->
 
 ---
 
-# Was ist ein Bild?
+<!-- _class: lead -->
 
-**Digital = Pixelraster**
+# Digitale Bilder
+## Raster- und Vektorgrafiken
 
-**Beispiel: 1920×1080 (Full HD)**
+---
+
+# Was ist ein digitales Bild?
+
+**Rasterbild = Pixelraster**
+
+**Beispiel: Full HD (1920×1080)**
 = 2.073.600 Pixel
 
 **Jedes Pixel = 3 Bytes (RGB)**
 2.073.600 × 3 = **6,2 MB**
 
-**Für EIN Foto!**
-
 <!--
-Zoom auf Pixel-Ebene zeigen
-Jedes Pixel = RGB-Tripel (3 Bytes)
+Zoom auf Pixel-Ebene zeigen.
+Jedes Pixel = RGB-Tripel (3 Bytes für 24-Bit-Farbe)
 6 MB × 10.000 Fotos = 62 GB
-Smartphone-Speicher wäre schnell voll ohne Kompression
+Smartphone-Speicher wäre ohne Kompression sofort voll.
 -->
 
 ---
@@ -137,37 +160,56 @@ Smartphone-Speicher wäre schnell voll ohne Kompression
 <!-- _footer: '' -->
 <!-- _backgroundColor: #e3f2fd -->
 
-# Rastergrafiken (Bitmaps)
+# Rastergrafiken
 
-**Aufbau:** 2D-Array von Pixeln mit Farbwerten
+**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
 
 **Speicherbedarf (unkomprimiert):**
 Breite × Höhe × Farbtiefe (in Bytes)
-→ 1920×1080 × 3 Byte (RGB) = **6,2 MB**
 
 **Farbtiefe:**
-- 1 Bit = 2 Farben (S/W)
-- 8 Bit = 256 Farben (Graustufen/Palette)
-- 24 Bit = 16,7 Mio. Farben (True Color)
-- 32 Bit = True Color + Alpha (Transparenz)
-
-**Skalierung:** Interpolation (Nearest Neighbor, Bilinear, Bicubic)
+| Bits | Farben | Anwendung |
+|-----:|-------:|-----------|
+| 1 | 2 | Schwarz/Weiß (Fax) |
+| 8 | 256 | Graustufen, GIF |
+| 24 | 16,7 Mio. | True Color (Standard) |
+| 32 | 16,7 Mio. + Alpha | Transparenz |
 
 <!--
-DEFINITION: Bitmap = Bit-mapped graphics, 2D-Matrix aus Pixeln
-BERECHNUNG SPEICHERBEDARF: Breite × Höhe × (Farbtiefe / 8)
+BERECHNUNG: Breite × Höhe × (Farbtiefe / 8)
 BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB
-FARBTIEFE erklärt:
-- 1 Bit: 2^1 = 2 Farben (Schwarz/Weiß, Fax)
-- 8 Bit: 2^8 = 256 Farben (GIF, Graustufen)
-- 24 Bit: 2^24 = 16.777.216 Farben (True Color, RGB je 8 Bit)
-- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal (Transparenz)
-INTERPOLATION bei Skalierung:
-- Nearest Neighbor: Schnell, pixelig (Pixel-Art)
-- Bilinear: Mittelwert aus 4 Nachbarn (Standard)
-- Bicubic: 16 Nachbarn, glatter (Photoshop-Standard)
-- Lanczos: Beste Qualität, rechenintensiv
-PRÜFUNGSRELEVANT: Speicherberechnung, Farbtiefe-Tabelle, warum Vergrößern problematisch
+
+Farbtiefe erklärt:
+- 1 Bit: 2^1 = 2 Farben
+- 8 Bit: 2^8 = 256 Farben
+- 24 Bit: 2^24 = 16.777.216 Farben (je 8 Bit für R, G, B)
+- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal
+-->
+
+---
+
+# Das Problem der Skalierung
+
+**Vergrößern:**
+Fehlende Pixel müssen erfunden werden (Interpolation)
+
+**Verkleinern:**
+Pixel müssen zusammengefasst werden
+
+**Interpolationsverfahren:**
+- Nearest Neighbor: Schnell, pixelig
+- Bilinear: Standard, glättet
+- Bicubic: Hohe Qualität, rechenintensiv
+- Lanczos: Beste Qualität
+
+<!--
+Nearest Neighbor: Gut für Pixel-Art (soll pixelig bleiben)
+Bilinear: Mittelwert aus 4 Nachbarn
+Bicubic: 16 Nachbarn, Photoshop-Standard
+Lanczos: Mathematisch aufwendig, beste Ergebnisse
+
+Das fundamentale Problem: Rasterbilder haben eine native Auflösung.
+Alles darüber ist Schätzung.
 -->
 
 ---
@@ -185,118 +227,219 @@ PRÜFUNGSRELEVANT: Speicherberechnung, Farbtiefe-Tabelle, warum Vergrößern pro
 - Text (Glyphen als Outlines)
 
 **SVG-Beispiel:**
-`<circle cx="50" cy="50" r="40" fill="#ff0000"/>`
-→ 3 Parameter statt 5.027 Pixel (r=40)
+```xml
+<circle cx="50" cy="50" r="40" fill="#ff0000"/>
+```
 
-**Rendering-Pipeline:**
+<small>SVG beschreibt nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden.</small>
+
+<!--
+Vektorgrafiken beschreiben WAS gezeichnet werden soll.
+Rastergrafiken beschreiben WIE jeder Pixel aussieht.
+
+Rendering-Pipeline:
 Vektordaten → Rasterisierung → Framebuffer → Display
 
-**Auflösungsunabhängig:** Gleiche Datei für Icon (32px) und Plakat (3m)
-
-<!--
-PRIMITIVE: Grundbausteine der Vektorgrafik
-- Pfade: Sequenz von Punkten, verbunden durch Linien/Kurven
-- Bézierkurven: Quadratisch (3 Kontrollpunkte), Kubisch (4 Kontrollpunkte)
-- Formen: Rechteck, Ellipse, Polygon (intern als Pfade)
-SVG-SYNTAX Beispiele:
-- <rect x="0" y="0" width="100" height="50"/>
-- <circle cx="50" cy="50" r="25"/>
-- <path d="M 0 0 L 100 100"/> (MoveTo, LineTo)
-BERECHNUNG: Kreis mit r=40 → Fläche = π×40² ≈ 5.027 Pixel vs. 3 Parameter
-RENDERING-PIPELINE: Vector → Tessellation → Rasterization → Framebuffer
-FORMATE:
-- SVG: XML-basiert, Web-Standard, editierbar
-- PDF: Seiten-Beschreibungssprache, Vektoren + Raster gemischt
-- AI/EPS: Adobe-proprietär, Druckvorstufe
-PRÜFUNGSRELEVANT: Warum Vektoren skalierbar, SVG-Grundsyntax, Rendering-Pipeline
+Beim Skalieren werden einfach die Koordinaten multipliziert.
+Keine Information geht verloren.
 -->
 
 ---
 
-<!-- _class: klausur -->
+# Raster- und Vektorgrafiken
+
+| | Raster | Vektor |
+|---|---|---|
+| **Optimal für** | Fotos, komplexe Bilder | Logos, Icons, Illustrationen |
+| **Skalierung** | Qualitätsverlust | Verlustfrei |
+| **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität |
+| **Formate** | JPEG, PNG, WebP | SVG, PDF, AI |
+| **Bearbeitung** | Pixel-basiert | Objekt-basiert |
+| **Kompression** | Verlustbehaftet | Verlustfrei |
+
+<!--
+Die Entscheidung hängt vom Inhalt ab:
+- Foto: Immer Raster (Millionen unterschiedlicher Pixel)
+- Logo: Immer Vektor (wenige geometrische Formen)
+- Screenshot: Meist Raster, aber für UI-Elemente manchmal Vektor
+
+Konvertierung:
+- Vektor → Raster: Trivial (Rasterisierung)
+- Raster → Vektor: Komplex, oft unbefriedigend (Tracing)
+-->
+
+---
+
+<!-- _class: lead -->
+
+# JPEG
+## Psychovisuell komprimieren
+
+---
+
+# Die Schwächen des Auges
+
+**Menschen sehen:**
+* Helligkeit besser als Farbe
+* Große Flächen besser als feine Details
+* Niedrige Frequenzen besser als hohe
+
+**JPEG nutzt das aus:**
+* Farbauflösung reduzieren (aber Helligkeit behalten)
+* Glatte Flächen effizient speichern
+* Hohe Frequenzen (Details) verwerfen
+
+<!--
+Das ist die visuelle Entsprechung zur Psychoakustik.
+
+Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen)
+als für Farbe (Zapfen).
+
+Hohe Frequenzen = schnelle Wechsel = feine Details
+Niedrige Frequenzen = langsame Wechsel = große Flächen
+-->
+
+---
+
+# JPEG: Schritt 1 – Farbraum
+
+**RGB → YCbCr** (auch 3 Werte pro Pixel, nur anders aufgeteilt)
+
+- **Y** = Helligkeit (Luminanz) – Was das Auge am besten sieht
+- **Cb** = Blau-Gelb-Anteil (Chrominanz)
+- **Cr** = Rot-Grün-Anteil (Chrominanz)
+
+**Warum diese Trennung?**
+Y (Helligkeit) behält volle Auflösung.
+Cb/Cr (Farbe) kann reduziert werden – Auge merkt es kaum.
+
+<!--
+YCbCr ist wie RGB ein Tripel aus 3 Werten pro Pixel.
+Der Unterschied: Statt Rot-Grün-Blau speichern wir Helligkeit + 2 Farbdifferenzen.
+
+Die Umrechnung ist reversibel (mathematische Transformation).
+Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
+-->
+
+---
+
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
 
-# Raster vs. Vektor: Entscheidungskriterien
+![bg contain](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png)
 
-| Kriterium | Raster | Vektor |
-|---|---|---|
-| **Speicherung** | Pixelmatrix | Geometrie + Attribute |
-| **Skalierung** | Qualitätsverlust | Verlustfrei |
-| **Komplexität** | O(Breite × Höhe) | O(Anzahl Objekte) |
-| **Bearbeitung** | Pixelbasiert | Objektbasiert |
+---
 
-**Wann Raster?** Fotos, Texturen, komplexe Farbverläufe
-**Wann Vektor?** Logos, Icons, Typografie, technische Zeichnungen
+# JPEG: Schritt 2 – Chroma Subsampling
 
-**Konvertierung:**
-- Raster → Vektor: Tracing (verlustbehaftet, approximiert)
-- Vektor → Raster: Rasterisierung (exakt, aber auflösungsgebunden)
+**Die Notation `J:a:b`** (bezogen auf einen 4×2 Pixel-Block):
+- **J** = Referenzbreite (immer 4)
+- **a** = Farbsamples in Zeile 1
+- **b** = Farbsamples in Zeile 2
+
+| Schema | Bedeutung | Farbdaten |
+|--------|-----------|-----------|
+| 4:4:4 | Jedes Pixel hat Farbinfo | 100% |
+| 4:2:2 | Jedes 2. Pixel horizontal | 50% |
+| 4:2:0 | Jedes 4. Pixel (2×2 Block teilt sich Farbe) | 25% |
+
+**4:2:0 ist JPEG-Standard** – kaum sichtbarer Unterschied.
 
 <!--
-KOMPLEXITÄT erklärt:
-- Raster O(w×h): Speicher wächst mit Pixelanzahl
-- Vektor O(n): Speicher wächst mit Objektanzahl
-BEISPIEL: Foto einer Wiese
-- Raster: 1920×1080 = 2 Mio. Pixel, komprimiert ~500 KB
-- Vektor: Jeder Grashalm ein Pfad → Millionen Objekte, unkomprimierbar
-KONVERTIERUNG:
-- Raster→Vektor (Tracing): Kantenerkennung, verlustbehaftet
-  - Tools: Potrace (Open Source), Adobe Live Trace, Inkscape
-  - Funktioniert gut: Logos, Zeichnungen, Text
-  - Funktioniert schlecht: Fotos, Farbverläufe
-- Vektor→Raster (Rasterisierung): Exakt, aber Auflösung fixiert
-  - Jeder Bildschirm macht das (GPU)
-  - Export: "Auflösung" wählen = Ziel-Pixelgröße
-ENTSCHEIDUNGSBAUM:
-- Foto/Screenshot? → Raster
-- Logo/Icon/Diagramm? → Vektor
-- Druckvorlage? → Vektor (Auflösungsunabhängig)
-- Web-Animation? → SVG (Vektor) oder Video (Raster)
-PRÜFUNGSRELEVANT: Wann welches Format, Konvertierungsrichtungen und deren Eigenschaften
+Beispiel 4:2:0: In einem 2×2-Block haben alle 4 Pixel denselben Cb/Cr-Wert,
+aber jedes Pixel behält seinen eigenen Y-Wert (Helligkeit).
+Das Auge merkt es kaum, weil Helligkeit erhalten bleibt.
 -->
 
 ---
 
-# Lossless: PNG
+# JPEG: Schritt 3 – DCT
 
-**PNG = Portable Network Graphics (1996)**
+**Discrete Cosine Transform:**
+Bild in 8×8-Pixel-Blöcke aufteilen.
+Jeden Block in **räumliche Frequenzen** zerlegen.
 
-**Funktionsweise:**
-- Vorhersage (Pixel ähneln Nachbarn)
-- Differenz-Encoding
-- DEFLATE-Algorithmus (wie ZIP)
+**Räumliche Frequenz = Wie schnell ändern sich Pixelwerte?**
+- **Niedrig:** Große, gleichmäßige Flächen (Himmel)
+- **Hoch:** Schnelle Wechsel, feine Details (Haare, Kanten)
 
-**Kompression:** 20-50% Ersparnis
+**Vorteil:** Die meiste Bildinformation steckt in niedrigen Frequenzen.
 
-**Gut für:** Screenshots, Logos, Text
-**Schlecht für:** Fotos
+<!--
+NICHT Tonhöhe! Räumliche Frequenz = Änderungsrate der Helligkeit im Raum.
 
-<!-- 
-PNG wurde entwickelt als GIF-Alternative (Patent-Probleme)
-Lossless: Originaldaten bleiben erhalten
-Transparenz: Alpha-Kanal (sanfte Übergänge)
-DEFLATE: Gleicher Algorithmus wie ZIP
+Niedrige Frequenz: Langsamer Übergang von hell zu dunkel
+Hohe Frequenz: Schneller Wechsel (z.B. Schachbrettmuster)
+
+DCT ist wie ein Prisma: Zerlegt das Bild in seine Frequenzkomponenten.
 -->
 
 ---
 
-# Lossy: JPEG
+# JPEG: Schritt 4 – Quantisierung
 
-**JPEG = Joint Photographic Experts Group (1992)**
+**Hier passiert der Datenverlust.**
 
-**Eigenschaften:**
-- Lossy Kompression
-- 90%+ Platzersparnis möglich
-- Artefakte bei hoher Kompression
+Hohe räumliche Frequenzen (Details) → grob speichern oder weglassen
+Niedrige Frequenzen (Flächen) → erhalten
 
-**6 MB → 500 KB** (typisch)
+**Der Quality-Schieberegler steuert das:**
+- Quality 100: Minimale Quantisierung
+- Quality 50: Aggressive Quantisierung
 
-<!-- 
-JPEG-Norm beschreibt nur Kompression, nicht Speicherformat
-JFIF = JPEG File Interchange Format (das eigentliche Dateiformat)
-Dateierweiterungen: .jpg, .jpeg, .jfif (alle gleich)
+<!--
+Quantisierung = Division durch Quantisierungsmatrix + Rundung.
+Je höher die Zahl in der Matrix, desto mehr wird verworfen.
+
+Quality 100 ist nicht verlustfrei! Es ist nur minimaler Verlust.
+-->
+
+---
+
+# JPEG: Schritt 5 – Zigzag & RLE
+
+**Nach Quantisierung:** Viele Werte sind 0 (v.a. hohe Frequenzen).
+
+**Zigzag-Scan:** Matrix diagonal durchlaufen
+→ Nullen sammeln sich am Ende
+
+```
+┌────────────────┐
+│ 1  2  6  7 ... │   Niedrig → Hoch
+│ 3  5  8 ...    │   (diagonal)
+│ 4  9 ...       │
+└────────────────┘
+```
+
+**RLE:** `0 0 0 0 0 0 0 0` → `(8, 0)` = "8 Nullen"
+
+<!--
+Zigzag sortiert so, dass Nullen am Ende stehen.
+Lange Null-Sequenzen sind ideal für RLE.
+-->
+
+---
+
+# JPEG: Schritt 6 – Huffman-Coding
+
+**Verlustfreie Kompression der Restwerte**
+
+**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge
+Häufige Werte bekommen kurze Bit-Sequenzen.
+
+| Zeichen | Häufigkeit | Code (Bit-Sequenz) |
+|---------|------------|------|
+| e | 40% | `0` (1 Bit) |
+| a | 25% | `10` (2 Bit) |
+| i | 20% | `110` (3 Bit) |
+| o | 10% | `1110` (4 Bit) |
+| u | 5% | `1111` (4 Bit) |
+
+<!--
+Huffman-Coding ist verlustfrei.
+Der "Code" ist eine Bit-Sequenz, die das Zeichen eindeutig identifiziert.
+Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
 -->
 
 ---
@@ -310,153 +453,161 @@ Dateierweiterungen: .jpg, .jpeg, .jfif (alle gleich)
 Beispiel: Stark komprimiertes JPEG
 Blocking (8×8-Blöcke sichtbar)
 Ringing (Geister um Kanten)
-Color Banding (Verläufe "treppig")
+Color Banding (Verläufe werden "treppig")
 -->
 
 ---
 
-# Wie funktioniert JPEG? (1/2)
+# JPEG-Artefakte
 
-**Schritt 1: RGB → YCbCr**
-- Y = Helligkeit (Luminanz)
-- Cb/Cr = Farbe (Chrominanz)
+**Bei hoher Kompression sichtbar:**
 
-**Warum?** Menschen sehen Helligkeit besser als Farbe
+**Blocking:**
+8×8-Blöcke werden sichtbar (Block-Grenzen)
 
-**Schritt 2: Chroma Subsampling**
-Farbauflösung reduzieren (4:2:0)
-→ 50% Datenmenge weg, kaum sichtbar
+**Ringing:**
+"Geister" um scharfe Kanten (Gibbs-Phänomen)
 
-<!-- 
-YCbCr = Farbraum-Konversion
-Y = Brightness, Cb = Blue-Yellow, Cr = Red-Green
-4:2:0 Subsampling: Farbe nur jedes 2. Pixel horizontal & vertikal
-Auge merkt's kaum, weil Helligkeitssehen dominiert
--->
-
----
-
-# Wie funktioniert JPEG? (2/2)
-
-**Schritt 3: DCT (Discrete Cosine Transform)**
-Bild in 8×8-Blöcke → Frequenzspektrum
-
-**Schritt 4: Quantisierung**
-Hohe Frequenzen (Details) stark reduzieren
-→ **Hier passiert Datenverlust!**
-
-**Schritt 5: Huffman-Coding**
-Lossless-Kompression der Restdaten
-
-<!-- 
-DCT: Ähnlich wie FFT bei Audio
-8×8 Blöcke: Warum JPEG "blocky" wird bei hoher Kompression
-Quantisierung: Quality-Schieberegler steuert genau das
-Huffman: Finale Effizienz (wie bei MP3)
--->
-
----
-
-# JPEG Qualität
-
-| Quality | Dateigröße | Artefakte |
-|---------|------------|-----------|
-| **100** | ≈2-3 MB | Kaum |
-| **85-90** | ≈200-400 KB | Minimal |
-| **50** | ≈100 KB | Sichtbar |
-
-**Sweet Spot: 85-90**
-10x Kompression, für Menschen kaum unterscheidbar
-
-<!-- 
-Quality 100 = Minimum Compression (nicht lossless!)
-Quality 85-90 = Standard für Web
-Quality 50 = Sichtbare Artefakte (Blocking, Ringing)
-Photoshop "Save for Web": Standard ist 60
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg](./assets/gif-animation.png)
+**Color Banding:**
+Farbverläufe werden stufig
 
 <!--
-GIF-Animation (z.B. Meme)
-256 Farben, aber Animationen möglich
+Diese Artefakte entstehen durch die 8×8-Block-Struktur
+und aggressive Quantisierung.
+
+Blocking: Benachbarte Blöcke werden unabhängig komprimiert.
+Ringing: DCT hat Probleme mit harten Kanten.
+Banding: Zu wenig Bits für feine Farbabstufungen.
 -->
 
 ---
 
-# Die GIF-Geschichte
+# JPEG-Qualität in der Praxis
 
-**GIF = Graphics Interchange Format (1987)**
-CompuServe (US-Online-Dienst)
+| Quality | Typische Größe (12 MP) | Artefakte |
+|--------:|----------------------:|-----------|
+| 100 | 2-3 MB | Minimal |
+| 85-90 | 200-400 KB | Kaum sichtbar |
+| 60 | ~100 KB | Bei genauem Hinsehen |
+| 30 | ~50 KB | Deutlich sichtbar |
+
+**Sweet Spot: 85-90**
+~10× Kompression, für Menschen kaum unterscheidbar.
+
+<!--
+Quality 100 ist nicht "unkomprimiert".
+Es ist minimale Lossy-Kompression.
+
+Für Web und Social Media: 60-80 oft ausreichend.
+Für Archivierung: 90-100 oder gleich PNG/RAW.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Andere Bildformate
+## PNG, GIF, WebP, AVIF
+
+---
+
+# PNG: Verlustfrei mit Transparenz
+
+**PNG = Portable Network Graphics (1996)**
+
+**Entstehung:**
+GIF-Patent-Streit → Community entwickelt Alternative
 
 **Features:**
-- 256 Farben max (8-bit Palette)
-- Lossless (für Palette)
-- Animationen!
+- Verlustfrei (Lossless)
+- Alpha-Transparenz (8-Bit)
+- Millionen Farben (24/48 Bit)
+- Patent-frei
 
-**1994 Twist:** Unisys hält Patent auf LZW-Kompression
-→ Fordert Lizenzgebühren
+**Ideal für:** Grafiken, Screenshots, Text, Logos
 
-→ **"Burn All GIFs!" Kampagne**
+<!--
+PNG entstand als Reaktion auf die GIF-Lizenzprobleme.
+"PNG is Not GIF" war ein früher Slogan.
 
-<!-- 
-CompuServe: Früher Online-Dienst (1969-2009)
-LZW = Lempel-Ziv-Welch Compression
-Unisys Patent-Trolling: Erst Jahre nach GIF-Einführung
-Community-Reaktion: Boykott, Suche nach Alternative
-Ergebnis: PNG wurde entwickelt (1996)
+DEFLATE-Kompression (wie ZIP).
+Keine Qualitätsverluste, aber größer als JPEG für Fotos.
 -->
 
 ---
 
-# PNG vs. GIF
+# GIF: Der Meme-Veteran
 
-**GIF:**
-✓ Animationen
-✓ Breite Unterstützung
-❌ Nur 256 Farben
-❌ Patent-Probleme (bis 2003)
+**GIF = Graphics Interchange Format (1987)**
 
-**PNG:**
-✓ Millionen Farben
-✓ Alpha-Transparenz
-✓ Patent-frei
-❌ Keine Animationen (bis APNG, 2004)
+**Features:**
+- 256 Farben (8-Bit Palette)
+- Verlustfrei (für die gewählte Palette)
+- Animationen
 
-**Ergebnis:** PNG für Grafiken, GIF für Memes!
+**Das Patent-Drama:**
+1994 fordert Unisys Lizenzgebühren für LZW-Kompression.
+→ "Burn All GIFs!" Kampagne
+→ PNG als Alternative
 
-<!-- 
-APNG = Animated PNG (Firefox, Safari support)
-WebP (Google, 2010): Animationen + bessere Kompression
-GIF überlebte kulturell (Meme-Format)
-"GIF" Aussprache: "Jif" vs. "Gif" – ewiger Streit
+**Heute:** Kulturell unsterblich (Memes, Reaktionen)
+
+<!--
+CompuServe entwickelte GIF 1987.
+LZW = Lempel-Ziv-Welch Kompression.
+
+Patent lief 2004 aus, aber da war PNG längst etabliert.
+GIF überlebte wegen Animationen und Netzwerkeffekten.
+
+Die Aussprache "GIF" vs. "JIF" bleibt ewiger Streit.
+Der Erfinder sagt "JIF", das Internet sagt "GIF".
 -->
 
 ---
 
-# WebP & AVIF
+# WebP & AVIF: Moderne Alternativen
 
 **WebP (Google, 2010):**
-- Lossy UND Lossless
-- Animationen
+- Lossy und Lossless
+- Transparenz und Animationen
 - 25-35% kleiner als JPEG
 
 **AVIF (2019):**
 - Basiert auf AV1-Video-Codec
-- 50% kleiner als JPEG
-- HDR-Unterstützung
-- Patent-frei
+- 50% kleiner als JPEG, HDR, patent-frei
 
-<!-- 
-WebP: Von Google entwickelt, deshalb Skepsis
-AVIF: Alliance for Open Media (Google, Netflix, Amazon, Mozilla...)
-Browser-Support 2024: WebP fast überall, AVIF wachsend
-JPEG bleibt dominant (Kompatibilität!)
+**Browser-Support 2025:** WebP fast universell, AVIF wächst.
+
+<!--
+WebP nutzt VP8-Kompression (Googles Video-Codec).
+Skepsis wegen Google-Dominanz, aber technisch überlegen.
+
+AVIF kommt von der Alliance for Open Media.
+Noch besser als WebP, aber Encoding ist langsam.
+
+JPEG bleibt dominant wegen Kompatibilität.
+Alte Kameras, alte Software, alte Workflows.
+-->
+
+---
+
+# Formatwahl in der Praxis
+
+| Anwendung | Format |
+|-----------|--------|
+| Fotos fürs Web | JPEG (85), WebP |
+| Screenshots | PNG |
+| Logos, Icons | SVG, PNG |
+| Animationen | GIF, WebP, APNG |
+| Archivierung | TIFF, PNG, RAW |
+| Social Media | Was die Plattform erlaubt |
+
+<!--
+Die Wahl hängt vom Kontext ab.
+Kompatibilität schlägt oft Effizienz.
+
+TIFF für Archivierung: Unkomprimiert oder verlustfrei.
+RAW für Fotografen: Maximale Bearbeitungsmöglichkeit.
 -->
 
 ---
@@ -467,7 +618,7 @@ JPEG bleibt dominant (Kompatibilität!)
 ![bg](./assets/instagram-quality-loss.png)
 
 <!--
-Vorher/Nachher: Hochauflösend vs. Instagram-Upload
+Vorher/Nachher: Original vs. Instagram-Upload
 Sichtbare Qualitätsverluste
 -->
 
@@ -475,140 +626,136 @@ Sichtbare Qualitätsverluste
 
 # Warum Instagram eure Fotos "ruiniert"
 
-**Upload-Pipeline:**
-1. Dein Foto: 12 MP, 8 MB
-2. Instagram skaliert: max. 1080px
+**Die Upload-Pipeline:**
+1. Euer Foto: 12 MP, 8 MB
+2. Instagram skaliert: max. 1080px Breite
 3. Re-Kompression: JPEG Quality ~75
-4. Endgröße: 200-400 KB
+4. Ergebnis: 200-400 KB
 
 **Warum?**
-- Speicherkosten (Milliarden Fotos!)
-- Ladezeiten (Mobile)
-- Bandbreite (günstiger)
+- Speicherkosten (Milliarden Fotos)
+- Ladezeiten (Mobile-First)
+- Bandbreite (günstiger für alle)
 
-<!-- 
-Instagram ist keine Kunstgalerie
-Optimiert für Geschwindigkeit, nicht Qualität
-Facebook macht dasselbe
-Lösung: Portfolio-Websites (eigene Kontrolle)
--->
+<!--
+Instagram ist keine Kunstgalerie.
+Optimiert für Geschwindigkeit und Skalierung.
 
----
+Facebook, Twitter, alle machen das.
+Manche besser, manche schlechter.
 
-<!-- _class: aufgabe -->
-
-![bg contain right:25%](./assets/qr/squoosh.png)
-
-# Hands-On: Kompression vergleichen
-
-**Aufgabe (40 Min):**
-
-1. Hochauflösendes Foto (eigenes oder CC)
-2. Exportiere:
-   - PNG
-   - JPEG Q100, Q85, Q50
-   - WebP (optional)
-3. Tool: **[Squoosh.app](https://squoosh.app)** (Google-Tool)
-4. Vergleiche: Dateigrößen, sichtbare Unterschiede
-5. Wo werden Artefakte sichtbar?
-
-<!-- 
-Squoosh.app: Browser-basiert, keine Installation
-Side-by-Side-Vergleich mit Zoom
-Verschiedene Codecs testen
-Studis sollen selbst "Sweet Spot" finden
+Für Fotografen: Portfolio auf eigener Website,
+nicht auf Social Media verlassen.
 -->
 
 ---
 
 <!-- _class: lead -->
 
-# Teil 2: Video
-## Kompression & Codecs
+# Video
+## Bilder + Zeit + Audio
 
 ---
 
+# Das Größenproblem bei Video
+
+**4K-Video (3840×2160), unkomprimiert:**
+
+3840 × 2160 × 3 Bytes = **24,8 MB pro Frame**
+
+× 30 Frames/Sekunde = **744 MB/Sekunde**
+
+× 60 Sekunden = **44,6 GB pro Minute**
+
+**Ein 2-Stunden-Film: über 5 Terabyte**
+
+<!--
+Das ist der Grund, warum Video-Kompression existiert.
+Ohne sie wäre Streaming unmöglich.
+Blu-rays könnten nicht existieren.
+Netflix wäre undenkbar.
+-->
+
+---
+
+<!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
 
-![bg](./assets/netflix-4k.png)
+# Container und Codec
 
-<!-- 
-Netflix 4K-Streaming
-Unmöglich ohne moderne Codecs
--->
+**Container = Das Dateiformat (Beispiel: MP4)**
+Die "Box", die verschiedene Streams zusammenpackt:
+- Video-Stream
+- Audio-Stream(s)
+- Untertitel
+- Metadaten
 
----
+**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)**
+Entscheidet, WIE komprimiert wird.
 
-# Das Problem: Videos sind RIIIIIIIESIG
-
-**1 Minute 4K-Video (3840×2160):**
-
-- 30 fps (Bilder/Sekunde)
-- Jedes Bild: 24,8 MB (unkomprimiert)
-
-**Rechnung:**
-30 × 24,8 MB = **744 MB/Sekunde**
-× 60 Sekunden = **44,6 GB/Minute**
-
-**2-Stunden-Film: 5,3 TB!**
-
-<!-- 
-4K = 3840×2160 Pixel = 8,3 Megapixel pro Frame
-30 fps = Standard, Kino = 24 fps, Gaming = 60+ fps
-Ohne Kompression: Unmöglich zu streamen oder speichern
--->
-
----
-
-# Container: Das Dateiformat
-
-**Was ist ein Container?**
-Das Dateiformat – eine "Box", die verschiedene Streams zusammenpackt:
-- Video-Stream, Audio-Stream(s), Untertitel, Metadaten
-
-**Gängige Container:**
-- **MP4** (.mp4) – Web, Streaming
-- **MKV** (.mkv) – Archiv, viele Streams
-- **AVI** (.avi) – Legacy (veraltet)
-- **MOV** (.mov) – Apple-Ökosystem
 
 <!--
-Container = Verpackung, nicht der Inhalt
-Ein MP4 sagt nichts über die Qualität aus
-MKV kann beliebig viele Audio/Untertitel-Spuren haben
+Container ≠ Codec
+Das ist ein häufiges Missverständnis.
+
+MP4 ist ein Container, nicht ein Codec.
+Ein MP4 kann H.264, H.265 oder AV1 enthalten.
+
+Übrigens: JPEG ist ein Codec (für Bilder), kein Container.
+Bei Bildern fallen Container und Codec oft zusammen.
+
+Tools wie MediaInfo zeigen beide Informationen.
 -->
 
 ---
 
-# Codec: Der Kompressionsalgorithmus
+# Gängige Container
 
-**Was ist ein Codec?** (Coder/Decoder)
-Entscheidet, WIE Video/Audio komprimiert wird
-
-**Video-Codecs:**
-
-| Codec | Jahr | Verbreitung |
-|-------|------|-------------|
-| H.264/AVC | 2003 | Universell, überall |
-| H.265/HEVC | 2013 | 4K, effizient, Lizenzen |
-| VP9 | 2013 | YouTube, Google |
-| AV1 | 2018 | Zukunft, lizenzfrei |
-
-**Audio-Codecs:** AAC, MP3, Opus, FLAC
+| Container | Verwendung |
+|-----------|------------|
+| **MP4** (.mp4) | Web, Streaming, universell |
+| **MKV** (.mkv) | Archiv, viele Streams, offen |
+| **MOV** (.mov) | Apple-Ökosystem |
+| **WebM** (.webm) | Web, nur VP9/AV1 + Opus |
+| **AVI** (.avi) | Legacy, veraltet |
 
 <!--
-H.264 = De-facto-Standard seit 20 Jahren
-H.265 = 50% kleinere Dateien, aber teure Lizenzen
-AV1 = Open Source, Netflix/YouTube pushen es
+MP4 = MPEG-4 Part 14, ISO-Standard.
+MKV = Matroska (russisch: Matrjoschka-Puppen).
+WebM = Subset von Matroska für HTML5.
+
+MKV kann beliebig viele Audio- und Untertitelspuren haben.
+Beliebt für Filme mit mehreren Sprachen.
+-->
+
+---
+
+# Video-Codecs
+
+| Codec | Jahr | Status |
+|-------|------|--------|
+| **MPEG-4** | 1999 | Passender Codec zu .mp4 |
+| **H.264/AVC** | 2003 | Universal, überall |
+| **H.265/HEVC** | 2013 | Effizienter, aber Patente |
+| **VP9** | 2013 | YouTube, patent-frei |
+| **AV1** | 2018 | Zukunft, patent-frei |
+
+<!--
+H.264 ist der De-facto-Standard seit 20 Jahren.
+Hardware-Decoder in jedem Gerät seit ~2010.
+
+H.265 ist 50% effizienter, aber Patent-Chaos.
+Drei konkurrierende Patent-Pools.
+
+AV1 ist die Antwort: Offen, modern, aber Encoding ist langsam.
 -->
 
 ---
 
 # Container + Codec = Video
 
-**Das Zusammenspiel:**
-
 ```
 ┌─────────────────────────────┐
 │  Container (z.B. MP4)       │
@@ -618,82 +765,27 @@ AV1 = Open Source, Netflix/YouTube pushen es
 │  │ Audio-Stream (AAC)     │ │
 │  ├────────────────────────┤ │
 │  │ Untertitel (SRT)       │ │
+│  ├────────────────────────┤ │
+│  │ Metadaten              │ │
 │  └────────────────────────┘ │
 └─────────────────────────────┘
 ```
 
-**Häufiger Irrtum:** "Das ist eine MP4-Datei"
-→ Sagt nichts über den Codec aus!
-
 <!--
-Container ≠ Codec (häufiges Missverständnis!)
-MP4 ist KEIN Codec, sondern Container
-Ein MP4 kann H.264, H.265 oder AV1 enthalten
-Prüfen mit: MediaInfo, ffprobe
+Der Container ist die Verpackung.
+Der Codec bestimmt, wie der Inhalt komprimiert ist.
+
+Ein MP4 mit H.264 und ein MP4 mit H.265
+haben dieselbe Endung, aber unterschiedliche Inhalte.
 -->
 
 ---
 
-<!-- _header: '' -->
-<!-- _footer: '' -->
+<!-- _class: lead -->
 
-![bg](./assets/container-codec-diagram.png)
+# Video-Kompression
+## Raum und Zeit nutzen
 
-<!-- 
-Diagramm: Container mit verschiedenen Streams
-Video-Track (H.264)
-Audio-Track (AAC)
-Untertitel-Track (SRT)
-Metadaten (Titel, Künstler, etc.)
--->
-
----
-
-# Video-Kompression: Drei Prinzipien
-
-**1. Spatial Compression (Intra-Frame)**
-Jedes Bild einzeln (wie JPEG)
-→ I-Frames
-
-**2. Temporal Compression (Inter-Frame)**
-Nur Änderungen zwischen Bildern
-→ P-Frames, B-Frames
-
-**3. Motion Compensation**
-"Ball bewegt sich von A nach B"
-
-<!-- 
-Spatial: Innerhalb eines Bildes (JPEG-ähnlich)
-Temporal: Zwischen Bildern (zeitliche Redundanz)
-Motion Compensation: Intelligente Vorhersage
-→ 90%+ Effizienz durch temporale Kompression
--->
-
----
-
-# I-Frames, P-Frames, B-Frames
-
-**I-Frame (Intra):**
-Vollständiges Bild (wie JPEG)
-Groß, aber unabhängig
-
-**P-Frame (Predicted):**
-Referenziert vorherige Frames
-Viel kleiner
-
-**B-Frame (Bi-directional):**
-Referenziert vorherige UND zukünftige Frames
-Am effizientesten
-
-**GOP:** I - B - B - P - B - B - P - B - B - I
-
-<!-- 
-GOP = Group of Pictures (typisch 12-15 Frames)
-I-Frame: Alle 1-2 Sekunden nötig (für Seeking)
-P-Frame: "Pixel X bewegt sich 5px rechts"
-B-Frame: Komplex, aber beste Kompression
-Wenn du vorspulst: Sucht nach nächstem I-Frame
--->
 
 ---
 
@@ -704,8 +796,78 @@ Wenn du vorspulst: Sucht nach nächstem I-Frame
 
 <!--
 Visualisierung: I/P/B-Frame-Abhängigkeiten
-I-Frame = Vollbild (Keyframe), P/B-Frames speichern nur Unterschiede
-Quelle: https://www.canon.com.hk/cpx/en/technical/va_EOS_Movie_Compression_Options_All_I_and_IPB.html
+I-Frame = Vollbild (Keyframe)
+P/B-Frames speichern nur Unterschiede
+-->
+
+---
+
+# Drei Kompressionsprinzipien
+
+**1. Spatial Compression (Intra-Frame)**
+Jedes Bild einzeln komprimieren (wie JPEG)
+
+**2. Temporal Compression (Inter-Frame)**
+Nur Änderungen zwischen Bildern speichern
+
+**3. Motion Compensation**
+Bewegung beschreiben statt Pixel kopieren
+
+<!--
+Spatial: Innerhalb eines Bildes (räumlich)
+Temporal: Zwischen Bildern (zeitlich)
+
+Video hat massive zeitliche Redundanz.
+90% eines Frames ist oft identisch mit dem vorherigen.
+-->
+
+---
+
+# I-Frames, P-Frames, B-Frames
+
+**I-Frame (Intra):**
+Vollständiges Bild, unabhängig komprimiert
+Groß, aber Ankerpunkt für Navigation
+
+**P-Frame (Predicted):**
+Referenziert vorherige Frames
+Speichert nur Unterschiede
+
+**B-Frame (Bi-directional):**
+Referenziert vorherige UND zukünftige Frames
+Beste Kompression, aber komplexer
+
+<!--
+GOP = Group of Pictures
+Typisch: I - B - B - P - B - B - P - B - B - I
+
+I-Frames alle 1-2 Sekunden für Seeking.
+Wenn du im Video springst, sucht der Player den nächsten I-Frame.
+
+B-Frames sind am effizientesten, aber erfordern Lookahead.
+-->
+
+---
+
+# Motion Compensation
+
+**Idee:** Bewegung beschreiben statt Pixel kopieren.
+
+**Beispiel:**
+Frame 1: Ball bei Position (100, 200)
+Frame 2: Ball bei Position (120, 200)
+
+**Statt 2 komplette Frames:**
+"Ball bewegt sich 20 Pixel nach rechts"
+
+**Enormer Effizienzgewinn bei Video mit Bewegung.**
+
+<!--
+Motion Vectors beschreiben Bewegung von Blöcken.
+Der Decoder rekonstruiert das Bild aus Referenz + Bewegung.
+
+Funktioniert gut bei: Kameraschwenks, bewegten Objekten.
+Funktioniert schlecht bei: Szenenwechseln, Chaos (Konfetti).
 -->
 
 ---
@@ -715,234 +877,174 @@ Quelle: https://www.canon.com.hk/cpx/en/technical/va_EOS_Movie_Compression_Optio
 <!-- _footer: '' -->
 <!-- _backgroundColor: #e3f2fd -->
 
-# H.264 / AVC Codec (2003)
-### Der bisherige Platzhirsch
+# H.264 / AVC
+
+**Advanced Video Coding (2003)**
 
 **Warum dominant?**
-✓ Exzellente Kompression (100:1 möglich)
-✓ Hardware-Support (jedes Gerät seit ~2010)
-✓ YouTube, Netflix, Blu-ray – alles H.264
+- Exzellente Kompression (~100:1 möglich)
+- Hardware-Support in jedem Gerät seit ~2010
+- YouTube, Netflix, Blu-ray – alles H.264
 
 **Features:**
 - Variable Block-Größen (16×16 bis 4×4)
-- Deblocking-Filter
-- CABAC-Coding
+- Deblocking-Filter (reduziert Block-Artefakte)
 
-<!-- 
-AVC = Advanced Video Coding
-MPEG-4 Part 10 = H.264 (gleicher Standard)
-Revolutionierte Video-Streaming
-Hardware-Decoder in CPUs/GPUs → Batterie-schonend
-CABAC = Context-Adaptive Binary Arithmetic Coding
+<!--
+H.264 revolutionierte Video-Streaming.
+Ohne H.264 kein Netflix, kein YouTube in HD.
+
+Hardware-Decoder bedeutet: Kein CPU-Aufwand, kein Akku-Drain.
+Selbst billige Smartphones können H.264 abspielen.
 -->
 
 ---
 
 # Das Patent-Problem
 
-**H.264 ist NICHT frei!**
+**H.264 ist nicht frei.**
 
 **MPEG-LA (Patent Pool):**
 - 2.000+ Patente von ~30 Unternehmen
 - Apple, Microsoft, Sony, Panasonic...
 
 **Lizenzgebühren:**
-- Hardware-Decoder: $0,20/Einheit
-- Content-Distribution: Kostenlos für "Internet Broadcast"
+- Hardware-Decoder: $0,20 pro Einheit
+- "Internet Broadcast": Kostenlos (YouTube etc.)
 
-**Problem:** Open-Source-Projekte in Grauzone
+**Problem:** Open-Source-Projekte in Grauzone.
 
-<!-- 
+<!--
 MPEG-LA = Licensing Authority
-Firefox weigerte sich lange, H.264 zu supporten (Patent-Gründe)
-Chromium musste extern linken
-Patent-Pool: Firmen teilen Patente, gemeinsame Lizenzierung
-"Free to View" Klausel: YouTube etc. kostenlos
+Patent-Pool: Firmen teilen Patente, gemeinsame Lizenzierung.
+
+Firefox weigerte sich lange, H.264 zu unterstützen.
+Chromium musste extern linken.
+
+Die "Free to View"-Klausel gilt nur für Endnutzer-Streaming.
 -->
 
 ---
 
-# H.265 / HEVC Codec (2013)
+# H.265 / HEVC: Effizienter, aber...
 
-50% bessere Kompression als H.264
+**High Efficiency Video Coding (2013)**
 
-**ABER:** Patent-Desaster
+50% bessere Kompression als H.264.
 
-**Drei (!) konkurrierende Patent-Pools:**
+**Das Problem: Patent-Chaos**
+
+Drei konkurrierende Patent-Pools:
 - MPEG-LA
 - HEVC Advance
 - Velos Media
 
-→ Viele bleiben bei H.264 oder suchen Alternativen
+Unklare Kosten, rechtliche Unsicherheit.
+→ Viele bleiben bei H.264 oder wechseln zu AV1.
 
-<!-- 
-HEVC = High Efficiency Video Coding
-Technisch überlegen, aber juristisch Albtraum
-Apple nutzt HEVC (iPhone-Videos)
-Netflix zögert wegen Lizenzkosten
-Fragmentierung verzögert Adoption
--->
+<!--
+Technisch ist H.265 überlegen.
+4K-Streaming wäre ohne H.265/VP9/AV1 nicht praktikabel.
 
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg](./assets/youtube-vp9.png)
-
-<!-- 
-YouTube VP9-Logo
-Google's Patent-freie Alternative
+Aber die fragmentierte Lizenzsituation verhinderte Adoption.
+Apple nutzt HEVC (iPhone-Videos), Netflix zögert.
 -->
 
 ---
 
 # VP9: Googles Antwort
 
-**VP9 (2013):**
-Entwickelt von Google (On2-Akquisition)
+**VP9 (2013)**
+
+Google kaufte On2 Technologies (2010, $133M).
+VP8 → VP9 → (später) AV1
 
 **Eigenschaften:**
-✓ Ähnlich H.265-Kompression
-✓ KOSTENLOS, patent-frei (laut Google)
-✓ YouTube nutzt VP9 für 4K
+- Ähnliche Effizienz wie H.265
+- Patent-frei (laut Google)
+- YouTube nutzt VP9 für 4K
 
 **Nachteile:**
-❌ Hardware-Support langsam
-❌ Höherer CPU-Aufwand
-❌ Nicht universell wie H.264
+- Höherer CPU-Aufwand als H.264
 
-<!-- 
-On2 Technologies: Gekauft 2010 für $133M
-VP8 → VP9 → AV1 (Evolution)
-YouTube forciert VP9: 4K-Videos nur VP9/AV1
-Hardware-Decoder erst ab ~2016 (langsame Adoption)
+<!--
+YouTube forciert VP9: 4K-Videos nur in VP9 oder AV1.
+Das treibt die Adoption.
+
+Hardware-Decoder ab ~2016 in GPUs.
+Heute in allen modernen Geräten.
 -->
 
 ---
 
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg](./assets/av1-logo.png)
-
-<!-- 
-AV1-Logo
-Alliance for Open Media
--->
-
----
+![bg contain right:28%](./assets/AV1.png)
 
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
 <!-- _backgroundColor: #e3f2fd -->
 
-# AV1: Die Open-Source-Revolution
+# AV1: Die offene Zukunft
 
-**AV1 (2018):**
-Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
+**AV1 (2018)**
 
-**Ziel:** Patent-freier, moderner Codec
+**Alliance for Open Media:**
+Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
 
-**Features:**
-✓ 30% besser als H.265
-✓ Royalty-free, Open Source
-✓ 8K, HDR, hohe Frame-Rates
-✓ Erster Codec, der einen Grammy gewonnen hat (2025)
+**Eigenschaften:**
+- 30% besser als H.265
+- Royalty-free, Open Source
+- 8K, HDR, hohe Frame-Rates
 
 **Stand 2025:**
-YouTube, Netflix nutzen AV1 für 4K/8K
+YouTube und Netflix nutzen AV1 für 4K/8K
+Hardware-Encoder in aktuellen GPUs
 
-<!-- 
-AOM = Alliance for Open Media (2015 gegründet)
-Alle Big-Tech-Player vereint (historisch!)
-"Fuck you" an Patent-Mafia
-Problem: Encoding SEHR langsam (10-100x vs. H.264)
-Hardware-Encoder kommen (ab 2020er-GPUs)
+<!--
+AOM = Alliance for Open Media, gegründet 2015.
+Historisch: Konkurrierende Tech-Giganten vereint.
 
-Source: https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/
+Das Ziel: Nie wieder Patent-Chaos wie bei H.265.
+
+Problem: Encoding ist sehr langsam (10-100× vs. H.264).
+Hardware-Encoder lösen das zunehmend.
 -->
 
 ---
 
+
+<!-- _header: '' -->
+<!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
+
+![bg contain](./assets/av1-grammy.png)
+
+
+<!--
+
+---
+
 # Adaptive Bitrate Streaming
 
 **Problem:** Internet-Geschwindigkeit variiert
 
-**Lösung:** Mehrere Qualitäten parallel
+**Lösung:** Mehrere Qualitätsstufen parallel
 
 **MPEG-DASH / HLS:**
-- 4K (20 Mbps)
-- 1080p (5 Mbps)
-- 720p (2,5 Mbps)
-- 480p (1 Mbps)
-- 240p (0,5 Mbps)
+- 4K: 20 Mbps
+- 1080p: 5 Mbps
+- 720p: 2,5 Mbps
+- 480p: 1 Mbps
 
-Segmente: 2-10 Sekunden (Player wählt dynamisch)
+Player wählt dynamisch basierend auf Bandbreite.
 
-<!-- 
 DASH = Dynamic Adaptive Streaming over HTTP
 HLS = HTTP Live Streaming (Apple)
-Beide ähnlich, aber inkompatibel
-Manifest-Datei: Liste aller Qualitäten
-Player misst Bandbreite, wechselt live
-→ Warum Netflix plötzlich pixelig wird
--->
 
----
+Video in 2-10 Sekunden-Segmente aufgeteilt.
+Manifest-Datei listet alle verfügbaren Qualitäten.
 
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg](./assets/streaming-quality-switch.png)
-
-<!-- 
-Visualisierung: Qualitätswechsel während Playback
-Bandbreite schwankt → Player reagiert
--->
-
----
-
-# Container im Detail
-
-**MP4:** Standard für Web/Mobile, DRM-fähig (H.264, H.265, AV1)
-
-**MKV:** Open Source, beliebig viele Spuren (fast jeder Codec)
-
-**WebM:** Google/Web-optimiert (nur VP9/AV1 + Opus/Vorbis)
-
-<!-- 
-MP4 = MPEG-4 Part 14 (ISO-Standard)
-Matroska = Russisch: Matrjoschka (Puppen ineinander)
-WebM = Subset von Matroska (HTML5-Video)
-MKV vs. MP4: Offenheit vs. Kompatibilität
--->
-
----
-
-<!-- _class: aufgabe -->
-
-# Hands-On: Video analysieren
-
-**Aufgabe (40 Min):**
-
-**Tools:**
-- Desktop: FFmpeg, HandBrake, [MediaInfo](https://mediaarea.net/MediaInfoOnline)
-- Browser: [Squoosh.app](https://squoosh.app) (Bilder), [MediaInfo Online](https://mediaarea.net/MediaInfoOnline)
-- iOS/Android: MediaInfo App, VLC
-
-1. Download: CC-Video (Big Buck Bunny, ~1 Min)
-2. Analysiere: Container, Codec, Bitrate, Auflösung
-3. Konvertiere: H.264 vs. H.265 (gleiche Qualität)
-4. Vergleiche: Größen, Encoding-Zeit
-
-<!-- 
-Big Buck Bunny: Open-Source-Film (Blender Foundation)
-FFmpeg: Swiss Army Knife für Video
-HandBrake: GUI für FFmpeg (einfacher)
-MediaInfo: Detaillierte Datei-Analyse
-Encoding-Zeit: H.265 deutlich langsamer als H.264
+Deshalb wird Netflix manchmal plötzlich pixelig:
+Bandbreite sinkt → Player wechselt auf niedrigere Qualität.
 -->
 
 ---
@@ -952,7 +1054,7 @@ Encoding-Zeit: H.265 deutlich langsamer als H.264
 # Fragen & Diskussion
 
 **Kontakt:** mail@librete.ch
-**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
+**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)
 
 ---
 
@@ -963,5 +1065,55 @@ Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAli
 - Erlaubt Teilen & Anpassen mit Namensnennung
 - Adaptionen müssen unter gleicher Lizenz geteilt werden
 
-Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
 
+---
+
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg contain right:25%](./assets/qr/squoosh.png)
+
+# Selbstlernen: Bildkompression
+
+1. Öffne [squoosh.app](https://squoosh.app)
+2. Lade ein Foto hoch
+3. Vergleiche: JPEG (verschiedene Quality) vs. WebP vs. AVIF
+4. Beobachte: Dateigröße, Artefakte, Ladezeit
+
+**Fragen:**
+- Ab welcher Quality werden Artefakte sichtbar?
+- Wie viel kleiner ist WebP bei gleicher Qualität?
+
+<!--
+Squoosh ist ein Google-Tool zum Vergleichen von Bildformaten.
+Zeigt Live-Vergleich mit Schieberegler.
+
+Ziel: Ein Gefühl für Kompressionsraten entwickeln.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Selbstlernen: Video analysieren
+
+1. Video herunterladen (z.B. Big Buck Bunny)
+2. Mit MediaInfo analysieren: Container, Codec, Bitrate
+3. Optional: Mit HandBrake konvertieren
+   - H.264 vs. H.265 bei gleicher Qualität
+   - Größe und Encoding-Zeit vergleichen
+
+**Tools:**
+- [MediaInfo](https://mediaarea.net/MediaInfoOnline) (Online oder Desktop)
+- [HandBrake](https://handbrake.fr) (Desktop)
+
+<!--
+Big Buck Bunny: Open-Source-Film der Blender Foundation.
+Frei verfügbar, ideal zum Experimentieren.
+
+FFmpeg ist das mächtigste Tool, aber komplex.
+HandBrake bietet eine GUI für FFmpeg.
+-->