---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---

<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #1e5f8a;
  --color-dimmed: #4a4a6a;
}
section.invert {
  --color-foreground: #fff;
}
section {
  font-size: 1.7rem;
}
h1 {
  color: #1e5f8a;
}
section.invert h1 {
  color: #fff;
}
h2 {
  color: #1f2937;
}
pre {
  background: #0f0f23;
  color: #5fb3e4;
  border-radius: 8px;
  border-left: 3px solid #1e5f8a;
}
pre code {
  background: transparent;
  color: inherit;
}
code {
  background: #0f0f23;
  padding: 0.15em 0.4em;
  border-radius: 4px;
  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
}
section code:not(.hljs) { color: #5fb3e4 !important; }
section code.hljs { color: #f8f8f8 !important; }
a {
  color: var(--color-highlight);
}
section.klausur {
  background: repeating-linear-gradient(
    135deg,
    #e3f2fd,
    #e3f2fd 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.klausur {
    background: #e3f2fd !important;
  }
}
section.aufgabe {
  background: #e3f2fd !important;
}
section.aufgabe footer {
  display: none;
}
section.erklaerung {
  font-size: 1.1rem;
}
section.erklaerung h1 {
  font-size: 1.5rem;
  color: #1e5f8a;
  margin-bottom: 0.3rem;
}
section.erklaerung ul,
section.erklaerung ol {
  font-size: 1.0rem;
  line-height: 1.4;
}
section.erklaerung p {
  font-size: 1.0rem;
  line-height: 1.4;
}
section.erklaerung table {
  font-size: 0.9rem;
}
</style>

<!-- _class: invert -->
<!-- _header: '' -->
<!-- _backgroundColor: #000 -->

![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)

# Dateiformate, Schnittstellen, Speichermedien & Distributionswege

**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart

[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)

<!--
- Willkommen, kurze Vorstellung
- Heute: Teil 2 – Bilder und Video
- Ziel: Verstehen, WARUM Formate so funktionieren, nicht nur WAS sie tun
- Frage zum Einstieg: "Wer hat schon mal ein Bild für Instagram hochgeladen und sich gewundert, warum es danach schlechter aussieht?"
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/qr/slides-223015b.png)

<!--
- QR-Code scannen für Folien-Link
- Folien sind CC BY-SA lizenziert – dürft ihr nutzen und teilen
-->

---

<!-- _class: lead -->

# Teil 2: Bild- & Videoformate

<!--
- Drei große Blöcke heute:
  1. Digitale Bilder (Raster vs. Vektor)
  2. JPEG im Detail (die Magie der Kompression)
  3. Video (warum es nochmal komplizierter ist)
- Interaktive Demos zwischendurch
-->

---

# Warum verschiedene Dateiformate?

**Ein Dateiformat definiert:**
- Ob und wie Daten komprimiert werden
- Welche Metadaten enthalten sind
- Wie Daten *codiert* und *decodiert* werden (*Co·dec*)

| Ziel | Bild | Audio | Dokument |
|------|------|-------|----------|
| Kleine Dateien | JPEG | MP3 | — |
| Perfekte Qualität | PNG, RAW | FLAC | PDF |
| Animation/Video | GIF | — | — |
| Skalierbarkeit | SVG | — | PDF |

<!--
- Kernfrage: Warum nicht EIN Format für alles?
- Antwort: Jedes Format ist ein Kompromiss
- Frage an Studierende: "Was wäre wichtiger – kleine Datei oder perfekte Qualität?" → Kommt drauf an!
- Analogie: Werkzeugkasten – Hammer für Nägel, Schraubenzieher für Schrauben
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg](./assets/photo-comparison.png)

<!--
- Links: Original (hochauflösend)
- Rechts: Stark komprimiert
- Frage: "Wer sieht die Unterschiede?"
- Auf Blockartefakte und Unschärfe hinweisen
- Das ist der Preis für kleine Dateien
-->

---

<!-- _class: lead -->

# Digitale Bilder
## Raster- und Vektorgrafiken

<!--
- Zwei fundamental verschiedene Ansätze
- Raster: "Malen nach Zahlen" – jeder Punkt einzeln
- Vektor: "Bauanleitung" – Formen beschreiben
-->

---

# Was ist ein digitales Bild?

Ein digitales Bild ist ein Raster aus Farbpunkten (Pixel).
Jeder Pixel speichert einen RGB-Farbwert (3 Bytes).

**Beispiel: Full HD (1920×1080)**
= 2.073.600 Pixel × 3 Bytes = **6,2 MB**

<!--
- Pixel = Picture Element
- RGB = Rot, Grün, Blau (je 0-255)
- Rechenbeispiel gemeinsam durchgehen
- Frage: "Wie viele Fotos passen auf ein 64GB Smartphone?" → ca. 10.000 unkomprimiert
- Pointe: Ohne Kompression wäre Smartphone-Fotografie unmöglich
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# Rastergrafiken

**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)

**Speicherbedarf (unkomprimiert):**
Breite × Höhe × Farbtiefe (in Bytes)

**Beispiele:** JPEG, PNG, WebP

| Bits (Farbtiefe) | Farben | Anwendung |
|-----:|-------:|-----------|
| 1 | 2 | Schwarz/Weiß (Fax) |
| 8 | 256 | Graustufen, GIF |
| 24 | 16,7 Mio. | True Color (Standard) |
| 32 | 16,7 Mio. + Alpha | Transparenz |

<!--
KLAUSURRELEVANT:
- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
- Farbtiefe: 2^n Farben bei n Bit
- 24 Bit = 8 Bit pro Kanal (R, G, B)
- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Rastergrafik – Vertiefung

Ein Pixel ist die kleinste adressierbare Einheit. Bei 24-Bit-Farbtiefe speichert jeder Pixel drei 8-Bit-Werte (0–255) für Rot, Grün und Blau. Diese additive Farbmischung erzeugt 256³ = 16,7 Millionen mögliche Farbtöne.

**Speicherberechnung:** `Breite × Höhe × Bytes pro Pixel`

| Auflösung | Farbtiefe | Berechnung | Größe |
|-----------|-----------|------------|-------|
| 1920×1080 | 24 Bit (3 B) | 2.073.600 × 3 | 6,2 MB |
| 4K (3840×2160) | 24 Bit | 8.294.400 × 3 | 24,9 MB |
| 4K | 32 Bit (4 B) | 8.294.400 × 4 | 33,2 MB |

Der Alpha-Kanal (32 Bit) speichert Transparenz als Wert von 0 (unsichtbar) bis 255 (vollständig sichtbar). PNG nutzt dies für weiche Kanten; JPEG unterstützt keinen 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: Glättet, Standardverfahren
- Bicubic: Hohe Qualität, rechenintensiv
- Lanczos: Beste Qualität, mathematisch komplex

<!--
- Kernproblem: Rasterbilder haben EINE native Auflösung
- Alles darüber = Schätzung, Erfindung
- Demo-Idee: Bild in Photoshop/GIMP stark vergrößern
- Nearest Neighbor gut für Pixel-Art (soll pixelig bleiben)
- Frage: "Warum wird mein Profilbild manchmal unscharf?" → Plattform skaliert
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# Vektorgrafiken

**Speicherung als geometrische Primitive:**
- Pfade (Bézierkurven mit Kontrollpunkten)
- Grundformen (Rechteck, Ellipse, Polygon)
- Text (Glyphen als Outlines)

**SVG-Beispiel:**
```xml
<circle cx="50" cy="50" r="40" fill="#ff0000"/>
```

<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>

<!--
KLAUSURRELEVANT:
- Vektor = Beschreibung (deklarativ)
- Raster = Pixel für Pixel (imperativ)
- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
- SVG = Scalable Vector Graphics (Web-Standard)
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Vektorgrafik – Vertiefung

Vektorgrafiken speichern keine Pixel, sondern mathematische Beschreibungen: Koordinaten, Kurvenparameter (Bézier-Kontrollpunkte), Füllfarben, Strichstärken. Der Renderer berechnet die Pixel erst bei der Ausgabe – daher beliebig skalierbar.

**Bézier-Kurven** (Pierre Bézier, 1962, für Renault-Karosserien entwickelt):
- Definiert durch Ankerpunkte und Kontrollpunkte
- Kubische Bézier: 2 Anker + 2 Kontrollpunkte
- Mathematisch exakt reproduzierbar

| Aspekt | Raster | Vektor |
|--------|--------|--------|
| Skalierung 10× | Pixel sichtbar | Perfekt scharf |
| Foto-Realismus | Gut geeignet | Unpraktikabel |
| Dateigröße Logo | Wächst mit Auflösung | Konstant (~5 KB) |
| Editierbarkeit | Destruktiv | Nicht-destruktiv |

**Rasterisierung:** GPU wandelt Vektordaten in Pixel um. Geschieht bei jeder Darstellung neu – deshalb ist ein 4K-Monitor schärfer als ein 1080p-Monitor bei gleichem SVG.

---

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

<!--
- Entscheidungsregel:
  - Foto → immer Raster
  - Logo → immer Vektor
  - Screenshot → meist Raster
- Konvertierung:
  - Vektor → Raster: trivial (Rasterisierung)
  - Raster → Vektor: schwierig, oft unbefriedigend (Tracing)
- Frage: "Warum verschickt euch der Grafiker das Logo als .ai oder .svg?"
-->

---

<!-- _class: lead -->

# Menschliche Wahrnehmung
## Psychovisuelle Kompression

<!--
- Jetzt wird's spannend: Wie können wir 90% der Daten wegwerfen, ohne dass es auffällt?
- Antwort: Das menschliche Auge ist kein perfekter Sensor
- Wir nutzen seine Schwächen aus
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# 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 (Helligkeit behalten)
* Glatte Flächen effizient speichern
* Hohe Frequenzen (feine Details) verwerfen

<!--
KLAUSURRELEVANT:
- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
- Niedrig = langsame Änderung = große gleichmäßige Fläche
- Hoch = schnelle Änderung = feine Details, Kanten
- Analogie zur Psychoakustik bei MP3 (letztes Mal)
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Psychovisuelle Wahrnehmung – Vertiefung

Die Netzhaut enthält ~120 Mio. Stäbchen (Helligkeitswahrnehmung) aber nur ~6 Mio. Zapfen (Farbwahrnehmung). Dieses 20:1-Verhältnis erklärt, warum JPEG Farbinformationen stärker reduzieren kann als Helligkeitsinformationen.

**Räumliche Frequenz** beschreibt, wie schnell sich die Helligkeit über eine Bildfläche ändert:
- **Niedrig:** Himmel, Wand – große einheitliche Flächen
- **Hoch:** Haare, Texturen, Schrift – schnelle Wechsel

Das Auge ist ein Tiefpassfilter: Hohe Frequenzen (feine Details) werden schwächer wahrgenommen. JPEG verwirft daher zuerst die hohen Frequenzen – der Qualitätsverlust bleibt meist unsichtbar.

| Biologisches Limit | Ausnutzung in JPEG |
|-------------------|-------------------|
| Farbauflösung ~20× geringer | Chroma Subsampling (4:2:0) |
| Hohe Frequenzen unscharf | DCT + Quantisierung |
| Kontrast-Maskierung | Artefakte in Texturen versteckt |

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg contain 50%](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg)

<!--
- Kompressionsvergleich am Beispiel
- Von links nach rechts: zunehmende Kompression
- Frage: "Ab wo seht ihr deutliche Qualitätsverluste?"
- Zeigt: Viel Spielraum für "unsichtbare" Kompression
-->

---

![bg contain right:34%](./assets/Posterization_example.jpg)

# Grenzen der Kompression: JPEG-Artefakte

**Bei starker Kompression sichtbar:**

* **Posterization:**
  Farbverläufe werden stufig

* **Blocking:**
  8×8-Blöcke werden sichtbar

* **Ringing:**
  "Geister" an scharfen Kanten

<!--
- Artefakte = sichtbare Spuren der Kompression
- Blocking: Benachbarte 8×8-Blöcke unabhängig komprimiert
- Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen)
- Posterization: Zu wenig Bits für feine Farbabstufungen
- Demo: Stark komprimiertes JPEG zoomen
-->

---

# JPEG-Qualität in der Praxis

| 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 ≠ unkomprimiert (immer noch lossy!)
- Für Web/Social Media: 60–80 oft ausreichend
- Für Archivierung: 90–100 oder besser PNG/RAW
- Faustregel: Quality 85 = guter Kompromiss
-->

---

<!-- _class: lead -->

# JPEG-Kompression
## Sechs Schritte im Detail

<!--
- Jetzt: Unter die Haube schauen
- JPEG = Joint Photographic Experts Group (1992)
- Sechs Schritte, davon einer verlustbehaftet
- Interaktive Demo: https://claude.ai/public/artifacts/452e62f1-8525-442d-aa88-bf3795cab2c5
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

![bg right:20%](./assets/Barn-yuv.png)

# JPEG Schritt 1: Farbraumkonversion

**RGB → Y'CbCr**

- **Y** = Helligkeit (Luminanz)
- **Cb** = Blau-Gelb-Anteil (Chrominanz)
- **Cr** = Rot-Grün-Anteil (Chrominanz)

**Warum?**
Y (Helligkeit) behält volle Auflösung
Cb/Cr (Farbe) kann reduziert werden

<!--
KLAUSURRELEVANT:
- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
- Umrechnung ist reversibel (mathematische Transformation)
- Vorteil: Helligkeit und Farbe getrennt behandelbar
- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Farbraumkonversion – Vertiefung

RGB→YCbCr nutzt die Biologie des menschlichen Auges: 120 Mio. Stäbchen (Helligkeit) vs. nur 6 Mio. Zapfen (Farbe) – ein 20:1-Verhältnis. Die Transformation erfolgt über eine lineare Matrix:

```
Y  =  0.299·R + 0.587·G + 0.114·B
Cb = −0.169·R − 0.331·G + 0.500·B + 128
Cr =  0.500·R − 0.419·G − 0.081·B + 128
```

Die Gewichtung (G dominiert mit 59%) entspricht der spektralen Empfindlichkeit des Auges bei Tageslicht. Y enthält alle Schärfeinformation; Cb/Cr können reduziert werden.

**Chroma Subsampling – Notation J:a:b** (bezogen auf 4×2 Pixel):

| Schema | Farbdaten | Einsatz |
|--------|-----------|---------|
| 4:4:4 | 100% | Postproduktion, Grafik |
| 4:2:2 | 50% | Broadcast, Pro-Video |
| 4:2:0 | 25% | JPEG, H.264, Streaming |

Bei 4:2:0 teilen sich 4 Pixel einen Farbwert, behalten aber individuelle Helligkeit → 50% Dateneinsparung bei kaum sichtbarem Unterschied.

---

# JPEG Schritt 2: Chroma Subsampling

**Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block):
- **J** = Referenzbreite (immer 4)
- **a** = Farbsamples in Zeile 1
- **b** = Farbsamples in Zeile 2

| Schema | Bedeutung | Farbdaten |
|--------|-----------|-----------|
| 4:4:4 | Volle Farbauflösung | 100% |
| 4:2:2 | Halbe horizontale Auflösung | 50% |
| 4:2:0 | Viertel Auflösung (2×2 teilt Farbe) | 25% |

**4:2:0 ist JPEG-Standard**

<!--
- Beispiel 4:2:0: 4 Pixel teilen sich einen Farbwert, aber jeder hat eigene Helligkeit
- Auge merkt es kaum → psychovisuelle Kompression
- Bereits hier: 50% Datenreduktion ohne sichtbaren Verlust
- In Video noch wichtiger (weniger Bandbreite)
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg contain 70%](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png)

<!--
- Visualisierung der Subsampling-Schemata
- Obere Reihe: Luminanz (Y) – immer voll
- Untere Reihen: Chrominanz (Cb, Cr) – reduziert
- 4:2:0 am häufigsten (JPEG, Video)
-->

---

# JPEG Schritt 3: Block-Aufteilung

**Das Bild wird in 8×8-Pixel-Blöcke zerlegt**

Jeder Block wird unabhängig verarbeitet.
Bei 1920×1080: 240 × 135 = **32.400 Blöcke**

**Level Shift:**
Pixelwerte um −128 verschieben
- Vorher: 0 bis 255
- Nachher: −128 bis +127

**Warum?**
DCT arbeitet besser mit Werten um Null

<!--
- 8×8 = historischer Kompromiss (Rechenleistung 1992)
- Unabhängige Verarbeitung = Grund für Blocking-Artefakte
- Level Shift: Mathematische Vorbereitung für DCT
- Bei nicht durch 8 teilbaren Dimensionen: Padding am Rand
-->

---

# JPEG Schritt 4: DCT (Discrete Cosine Transform)

**Jeder 8×8-Block wird transformiert:**
64 Pixelwerte → 64 Frequenzkoeffizienten

**Die 64 Koeffizienten:**

| Position | Name | Bedeutung |
|----------|------|-----------|
| (0,0) | DC | Durchschnittshelligkeit |
| Rest | AC | Helligkeitsänderungen |

**Energy Compaction:**
90% der Information in den ersten 10–15 Koeffizienten
DCT selbst ist **verlustfrei** und reversibel!

<!--
- DCT = Herzstück von JPEG
- Ähnlich wie Fourier-Transformation, aber nur Cosinus
- Sortiert Information nach "Wichtigkeit"
- Niedrige Frequenzen (oben links) = wichtig
- Hohe Frequenzen (unten rechts) = Details, oft verzichtbar
- NICHT hier passiert der Verlust!
-->

---

# JPEG Schritt 5: Quantisierung

**Hier passiert der Datenverlust!**

Die DCT hat sortiert – jetzt wird aufgeräumt:
- Wichtige Werte (niedrige Frequenz) → präzise behalten
- Unwichtige Werte (hohe Frequenz) → vergröbern oder Null setzen

**Ergebnis:**
Von 64 Werten pro Block bleiben oft nur 5–15 übrig
Rest wird zu Nullen → extrem gut komprimierbar

**Quality-Einstellung:**
Hoch = mehr Werte behalten = größere Datei
Niedrig = mehr Nullen = kleinere Datei, mehr Artefakte

<!--
KLAUSURRELEVANT:
- Quantisierung = Division durch Quantisierungsmatrix + Runden
- Einziger verlustbehafteter Schritt!
- Quality 100 ≠ verlustfrei, nur "wenig wegwerfen"
- Quantisierungstabellen basieren auf Wahrnehmungsforschung
-->

---

![bg fit](./assets/quantized-image-8-colors.jpg)

<!-- _header: '' -->
<!-- _footer: 'https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization' -->

<!--
- Visualisierung von Quantisierung (hier: Farbreduktion)
- Prinzip gilt auch für DCT-Koeffizienten
- Weniger Stufen = weniger Daten = weniger Qualität
-->

---

# JPEG Schritt 5b: Zigzag & RLE

**Nach Quantisierung:** Viele Nullen (v.a. bei hohen Frequenzen)

**Zigzag-Scan:** Matrix diagonal durchlaufen
→ Nullen sammeln sich am Ende

```
┌────────────────┐
│ 1  2  6  7 ... │   Niedrig → Hoch
│ 3  5  8 ...    │   (diagonal)
│ 4  9 ...       │
└────────────────┘
```

**RLE (Run-Length Encoding):**
`0 0 0 0 0 0 0 0` → `(8, 0)` = "acht Nullen"

<!--
- Zigzag: Clever – sortiert so, dass Nullen am Ende stehen
- RLE: Klassische verlustfreie Kompression
- Lange Nullsequenzen → sehr kurze Codes
- Beispiel: "00000000" (8 Byte) → "(8,0)" (2 Byte)
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# JPEG Schritt 6: Huffman-Coding

**Verlustfreie Kompression der Restwerte**

**Idee:** Variable Bitlänge statt fester 8 Bit
Häufige Werte → kurze Codes

| Zeichen | Häufigkeit | Code |
|---------|------------|------|
| 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) |

<!--
KLAUSURRELEVANT:
- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
- Präfix-frei: Kein Code ist Anfang eines anderen
- Häufigstes Zeichen = kürzester Code
- Auch in ZIP, PNG, MP3 verwendet
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Huffman-Coding – Vertiefung

David Huffman entwickelte 1952 als Student am MIT einen optimalen Algorithmus für präfixfreie Codes – ursprünglich als Hausaufgabe, die zur Veröffentlichung führte.

**Algorithmus (Bottom-Up-Baumkonstruktion):**
1. Alle Symbole nach Häufigkeit sortieren
2. Die zwei seltensten Symbole zu einem Knoten kombinieren
3. Wiederholen bis nur noch die Wurzel übrig ist
4. Codes ablesen: links = 0, rechts = 1

**Präfixfreiheit:** Kein Code ist Anfang eines anderen → sofort dekodierbar ohne Trennzeichen.

| Eigenschaft | Huffman | Arithmetisch |
|-------------|---------|--------------|
| Einheit | Ganze Bits | Fraktionale Bits |
| Optimalität | Optimal für ganze Bits | Näher an Entropie |
| Geschwindigkeit | Schneller | Langsamer |
| JPEG-Einsatz | Standard (Baseline) | Optional (selten) |

JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittswerte), eine für AC-Koeffizienten (Frequenzen). Die Tabellen sind im JPEG-Header gespeichert.

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->
<!--
# Huffman-Coding: Beispiel

**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)

**Häufigkeitsanalyse:**
A=5, B=2, R=2, C=1, D=1

**Huffman-Baum → Codes:**
| Zeichen | Häufigkeit | Code |
|---------|------------|------|
| A | 5 | `0` |
| B | 2 | `10` |
| R | 2 | `110` |
| C | 1 | `1110` |
| D | 1 | `1111` |

**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
**Kompression:** 88 → 23 Bit = **74% gespart**


- Beispiel Schritt für Schritt durchrechnen
- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg](./assets/jpeg-artifacts.png)

<!--
- Zusammenfassung: Typische JPEG-Artefakte
- Blocking: 8×8-Struktur sichtbar
- Ringing: Geister um Kanten
- Color Banding: Farbverläufe werden stufig
- Alles Folgen der Quantisierung
-->

---

<!-- _class: lead -->

# Andere Bildformate
## PNG, GIF, WebP, AVIF

15:33 Uhr weiter

<!--
- JPEG ist nicht für alles geeignet
- Jetzt: Alternativen und ihre Stärken
-->

---

# PNG: Verlustfrei mit Transparenz

**PNG = Portable Network Graphics (1996)**

**Entstehung:** GIF-Patent-Streit → Community entwickelt Alternative

**Features:**
- Verlustfrei (Lossless)
- Alpha-Transparenz (8-Bit, 256 Stufen)
- Millionen Farben (24/48 Bit)
- Patent-frei

**Ideal für:** Grafiken, Screenshots, Text, Logos

<!--
- PNG entstand als Reaktion auf GIF-Lizenzprobleme
- "PNG is Not GIF" (rekursives Akronym)
- DEFLATE-Kompression (wie ZIP)
- Keine Qualitätsverluste, aber größer als JPEG für Fotos
- Transparenz mit 256 Stufen (nicht nur an/aus wie GIF)
-->

---

# GIF: Der Meme-Veteran

**GIF = Graphics Interchange Format (1987)**

**Features:**
- 256 Farben (8-Bit Palette)
- Verlustfrei (innerhalb der Palette)
- Animationen

**Das Patent-Drama (1994):**
Unisys fordert Lizenzgebühren für LZW-Kompression
→ "Burn All GIFs!"-Kampagne
→ PNG als Alternative

**Heute:** Kulturell unsterblich (Memes, Reaktionen)

<!--
- CompuServe entwickelte GIF 1987
- LZW = Lempel-Ziv-Welch Kompression
- Patent lief 2004 aus, aber PNG war da längst etabliert
- GIF überlebte wegen Animationen
- Aussprache: "GIF" vs. "JIF" – ewiger Streit (Erfinder sagt "JIF")
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# WebP & AVIF: Moderne Alternativen

**WebP (Google, 2010):**
- 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

**Browser-Support 2025:** WebP universell, AVIF wächst

<!--
KLAUSURRELEVANT:
- WebP: VP8-Kompression (Google Video-Codec)
- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
- Beide besser als JPEG, aber Kompatibilität bleibt Problem
- JPEG bleibt dominant: alte Kameras, Software, Workflows
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# WebP & AVIF – Vertiefung

**WebP** entstand 2010 aus Googles VP8-Videocodec (On2 Technologies, für $133M gekauft). Statt I-Frames für Video werden sie als Einzelbilder verwendet. WebP nutzt Intra-Frame-Prediction, die benachbarte Blöcke zur Vorhersage verwendet – effizienter als JPEGs blockweise DCT.

**AVIF** basiert auf dem AV1-Videocodec, entwickelt 2015–2018 von der Alliance for Open Media (Google, Apple, Netflix, Amazon, Microsoft, Mozilla). Nach dem Patent-Chaos von H.265/HEVC vereinten sich die Konkurrenten für einen lizenzfreien Standard.

| Aspekt | WebP | AVIF |
|--------|------|------|
| Basis-Codec | VP8/VP9 | AV1 |
| Kompression vs. JPEG | 25–35% besser | 50% besser |
| HDR/Wide Gamut | Nein | Ja (10/12 Bit) |
| Encoding-Geschwindigkeit | Schnell | Sehr langsam |
| Browser-Support 2025 | 97%+ | 93%+ |

**Warum JPEG dominiert:** Kameras, Bildbearbeitungssoftware und Content-Management-Systeme sind auf JPEG optimiert. Der Wechsel erfordert Infrastruktur-Updates über die gesamte Pipeline.

---

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

<!--
- Kompatibilität schlägt oft Effizienz
- TIFF für Archivierung: Unkomprimiert oder verlustfrei
- RAW für FotografInnen: Maximale Bearbeitungsfreiheit
- Frage: "Was passiert, wenn ihr ein PNG auf Instagram hochladet?"
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg](./assets/instagram-quality-loss.png)

<!--
- Vorher/Nachher: Original vs. Instagram-Upload
- Sichtbare Qualitätsverluste
- Warum? → Nächste Folie
-->

---

# Warum Instagram eure Fotos "ruiniert"

**Die Upload-Pipeline:**
1. Euer Foto: 12 MP, 8 MB
2. Instagram skaliert: max. 1080px Breite
3. Re-Kompression: JPEG Quality ~75
4. Ergebnis: 200–400 KB

**Warum?**
- Speicherkosten (Milliarden Fotos)
- Ladezeiten (Mobile-First)
- Bandbreite (günstiger für alle)

<!--
- Instagram ist keine Kunstgalerie, sondern Massenplattform
- Optimiert für Geschwindigkeit, nicht Qualität
- Facebook, Twitter, TikTok – alle machen das
- Tipp für FotografInnen: Portfolio auf eigener Website
- Diskussion: Ist das fair? Trade-off Nutzende vs. Plattform
-->

---

<!-- _class: lead -->

# Video
## Bilder + Zeit + Audio

<!--
- Jetzt wird's richtig interessant
- Video = viele Bilder + Ton + Synchronisation
- Das Größenproblem potenziert sich
- Interaktive Demo: https://claude.ai/public/artifacts/fd58ac94-6b64-4d93-82be-ffb648ed9897
-->

---

# Das Größenproblem bei Video

**4K-Video (3840×2160), unkomprimiert:**

3840 × 2160 × 3 Bytes = **24,8 MB pro Frame**

× 30 fps = **744 MB/Sekunde**

× 60 Sekunden = **44,6 GB pro Minute**

**Ein 2-Stunden-Film: über 5 Terabyte**

<!--
- Rechnung gemeinsam durchgehen
- Frage: "Wie groß ist ein Netflix-Film typischerweise?" → 3–7 GB
- Das ist Faktor 1000 Kompression!
- Ohne Video-Kompression: Kein Streaming, kein YouTube, keine Blu-rays
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# Container und Codec

**Container = Dateiformat (z.B. MP4)**
Die "Box", die verschiedene Streams zusammenpackt:
- Video-Stream
- Audio-Stream(s)
- Untertitel
- Metadaten

**Codec = Kompressionsalgorithmus (z.B. H.264)**
Bestimmt, WIE komprimiert wird

<!--
KLAUSURRELEVANT:
- Container ≠ Codec (häufiges Missverständnis!)
- MP4 kann H.264, H.265 oder AV1 enthalten
- Gleiche Endung, unterschiedlicher Inhalt
- Tool-Tipp: MediaInfo zeigt beides an
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# Container vs. Codec – Vertiefung

**Container** (Multiplexer-Format) organisiert mehrere Datenströme mit Timing-Informationen. Er enthält keine Kompressionslogik, sondern synchronisiert Video, Audio, Untertitel und Metadaten.

**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.

| Container | Entwicklung | Typische Codecs | Besonderheit |
|-----------|------------|-----------------|--------------|
| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig |
| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel |
| WebM | Google | VP9, AV1, Opus | HTML5-optimiert, lizenzfrei |
| MOV | Apple | ProRes, H.264 | Professionelle Produktion |

**Metadaten im Container:**
- Timecodes für Frame-genaue Synchronisation
- Kapitelmarken, Thumbnails
- Sprach-Tags für Audio/Untertitel
- HDR-Metadaten (MaxCLL, MaxFALL)

**Praktisches Problem:** Eine `.mp4`-Datei mit AV1-Codec spielt auf älteren Geräten nicht ab, obwohl sie MP4 „unterstützen" – der Hardware-Decoder fehlt für AV1.

---

# Gängige Container

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

<!--
- MP4 = MPEG-4 Part 14, ISO-Standard
- MKV = Matroska (russische Matrjoschka-Puppen)
- WebM = Subset von Matroska für HTML5
- MKV beliebt für Filme mit mehreren Sprachen
- AVI: Bitte nicht mehr verwenden
-->

---

# Video-Codecs im Überblick

| Codec | Jahr | Status |
|-------|------|--------|
| **H.264/AVC** | 2003 | Universal, überall |
| **H.265/HEVC** | 2013 | Effizienter, Patent-Chaos |
| **VP9** | 2013 | YouTube, patent-frei |
| **AV1** | 2018 | Zukunft, patent-frei |

<!--
- H.264: De-facto-Standard seit 20 Jahren, Hardware-Decoder überall
- H.265: 50% besser, aber drei konkurrierende Patent-Pools
- VP9: Google kaufte On2 Technologies, forciert über YouTube
- AV1: Alliance for Open Media – die Tech-Giganten vereint
-->

---

# Container + Codec = Video

```
┌─────────────────────────────┐
│  Container (z.B. MP4)       │
│  ┌────────────────────────┐ │
│  │ Video-Stream (H.264)   │ │
│  ├────────────────────────┤ │
│  │ Audio-Stream (AAC)     │ │
│  ├────────────────────────┤ │
│  │ Untertitel (SRT)       │ │
│  ├────────────────────────┤ │
│  │ Metadaten              │ │
│  └────────────────────────┘ │
└─────────────────────────────┘
```

<!--
- Container = Verpackung
- Codec = wie der Inhalt komprimiert ist
- Ein MP4 mit H.264 und ein MP4 mit H.265 haben dieselbe Endung
- Wichtig für Kompatibilität: Player muss Codec unterstützen
-->

---

<!-- _class: lead -->

# Video-Kompression
## Raum und Zeit nutzen

<!--
- Video hat zwei Dimensionen der Redundanz:
  1. Räumlich (innerhalb eines Frames) – wie bei JPEG
  2. Zeitlich (zwischen Frames) – neu!
- Die zeitliche Redundanz ist der Schlüssel
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/ipb-compression-canon.jpg)

<!--
- Visualisierung: I/P/B-Frame-Abhängigkeiten
- I-Frame = Vollbild (Keyframe)
- P-Frame = Vorwärts-Referenz
- B-Frame = Bidirektionale Referenz
- Mehr dazu auf den nächsten Folien
-->

---

# 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 = räumlich, innerhalb eines Bildes
- Temporal = zeitlich, zwischen Bildern
- Motion Compensation = Bewegungsvektoren
- 90% eines Frames oft identisch mit dem vorherigen!
- Kernidee: Warum zweimal speichern, was sich nicht ändert?
-->

---

# Spatial Compression (Intra-Frame)

**Jedes Bild einzeln komprimieren – wie JPEG**

Analysiert Redundanz *innerhalb* eines Frames:
- DCT (Frequenzanalyse)
- Quantisierung
- Entropie-Coding

**→ I-Frame (Keyframe)**
Vollständiges Bild, unabhängig dekodierbar

<!--
- I = Intra = innerhalb
- I-Frames sind groß, aber wichtig für:
  - Seeking (Springen im Video)
  - Fehlerkorrektur
  - Schnitt
- Typisch alle 1–2 Sekunden ein I-Frame
-->

---

# Temporal Compression (Inter-Frame)

**Nur Änderungen zwischen Bildern speichern**

| Frame-Typ | Referenziert | Typische Größe |
|-----------|--------------|----------------|
| **I-Frame** | Nichts (Keyframe) | 100% |
| **P-Frame** | Vorherige Frames | ~30% |
| **B-Frame** | Vorherige + zukünftige | ~15% |

**GOP (Group of Pictures):**
I - B - B - P - B - B - P - B - B - I

<!--
KLAUSURRELEVANT:
- I = Intra (vollständig)
- P = Predicted (vorhergesagt aus Vergangenheit)
- B = Bi-directional (Vergangenheit + Zukunft)
- B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung
- GOP-Länge beeinflusst Seeking-Geschwindigkeit
-->

---

# Motion Compensation

**Bewegung beschreiben statt Pixel kopieren**

**Beispiel:** Ein 16×16 Pixel-Block

Frame 1: Block an Position (100, 200)
Frame 2: Block an Position (120, 200)

**Statt Block zweimal speichern:**
→ Motion Vector: "verschiebe um (+20, 0)"

<!--
- Macroblocks: Typisch 16×16 oder variable Größen
- Motion Vectors beschreiben Verschiebung
- Funktioniert gut bei: Kameraschwenks, bewegte Objekte
- Funktioniert schlecht bei: Szenenwechsel, Konfetti, Feuerwerk
- Demo: Video Frame für Frame durchgehen
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/ipb-compression-canon.jpg)

<!--
- Nochmal das Bild mit dem neuen Wissen betrachten
- Pfeile zeigen Abhängigkeiten
- B-Frames referenzieren in beide Richtungen
- Frage: "Was passiert, wenn ein I-Frame beschädigt ist?"
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# H.264 / AVC

**Advanced Video Coding (2003)**

**Warum dominant?**
- Exzellente Kompression (~100:1 möglich)
- Hardware-Decoder 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 (reduziert Artefakte)

<!--
KLAUSURRELEVANT:
- H.264 revolutionierte Video-Streaming
- Ohne H.264 kein Netflix, kein YouTube HD
- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
- Selbst billigste Smartphones können H.264 abspielen
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# H.264/AVC – Vertiefung

H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-ray. Vor H.264 war MPEG-2 Standard – H.264 erreichte bei gleicher Qualität die halbe Bitrate.

**Technische Innovationen:**
- **Variable Blockgrößen:** 16×16 bis 4×4 Macroblocks (MPEG-2: nur 16×16)
- **Intra-Prediction:** Blöcke werden aus Nachbarn vorhergesagt
- **In-Loop Deblocking:** Filter reduziert Blockartefakte vor der Referenzierung
- **CABAC:** Arithmetic Coding ersetzt Huffman (10–15% effizienter)

| Profile | Anwendung | Max. Auflösung |
|---------|-----------|----------------|
| Baseline | Videotelefonie, ältere Geräte | 480p |
| Main | Broadcast, Streaming | 1080p |
| High | Blu-ray, professionell | 4K |

**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.

**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzungs-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.

---

# Das Patent-Problem

**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 pro Einheit
- "Internet Broadcast": Kostenlos (YouTube etc.)

**Problem:** Open-Source-Projekte in Grauzone

<!--
- MPEG-LA = Licensing Authority
- Firefox weigerte sich lange, H.264 zu unterstützen
- "Free to View" gilt nur für Endnutzungs-Streaming
- Diskussion: Sollten Standards patent-frei sein?
-->

---

# H.265 / HEVC: Effizienter, aber...

**High Efficiency Video Coding (2013)**

50% bessere Kompression als H.264

**Das Problem: Patent-Chaos**

Drei konkurrierende Patent-Pools:
- MPEG-LA
- HEVC Advance
- Velos Media

Unklare Kosten, rechtliche Unsicherheit
→ Viele bleiben bei H.264 oder wechseln zu AV1

<!--
- Technisch überlegen, aber Lizenz-Albtraum
- 4K-Streaming wäre ohne H.265/VP9/AV1 nicht praktikabel
- Apple nutzt HEVC (iPhone-Videos)
- Netflix zögerte lange
- Lehre: Technische Überlegenheit reicht nicht
-->

---

# VP9: Googles Antwort

**VP9 (2013)**

Google kaufte On2 Technologies (2010, $133M)
VP8 → VP9 → AV1

**Eigenschaften:**
- Ähnliche Effizienz wie H.265
- Patent-frei (laut Google)
- YouTube nutzt VP9 für 4K

**Nachteil:** Höherer CPU-Aufwand als H.264

<!--
- YouTube forciert VP9: 4K-Videos nur in VP9 oder AV1
- Hardware-Decoder ab ~2016 in GPUs
- Google's Strategie: Eigene Infrastruktur als Hebel
- Frage: Ist es gut, wenn ein Konzern Standards setzt?
-->

---

![bg contain right:28%](./assets/AV1.png)

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# AV1: Die offene Zukunft

**AV1 (2018)**

**Alliance for Open Media:**
Google, Netflix, Amazon, Microsoft, Apple, Mozilla...

**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
Hardware-Encoder in aktuellen GPUs

<!--
KLAUSURRELEVANT:
- AOM gegründet 2015 – historisch: Konkurrenten vereint
- Ziel: Nie wieder Patent-Chaos wie bei H.265
- Problem: Encoding sehr langsam (10–100× vs. H.264)
- Hardware-Encoder lösen das zunehmend
- AV1 gewann 2024 einen Emmy für technische Innovation
-->

---

<!-- _class: erklaerung -->
<!-- _header: '' -->
<!-- _footer: '' -->

# AV1 – Vertiefung

Die **Alliance for Open Media** (2015) vereinte Konkurrenten nach dem Patent-Chaos von H.265/HEVC. Drei separate Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) machten H.265-Lizenzierung unberechenbar – die Industrie wollte einen garantiert lizenzfreien Standard.

**Gründungsmitglieder:** Google, Mozilla, Cisco, Netflix, Amazon, Microsoft. Apple trat 2018 bei – historisch, da Apple sonst eigene Standards bevorzugt.

| Technische Innovation | Beschreibung |
|----------------------|--------------|
| Superblocks | Bis 128×128 Pixel (H.264: max 16×16) |
| Prediction Modes | 56 Intra-Modi (H.264: 9) |
| Transform | 10 verschiedene Transformtypen |
| Film Grain Synthesis | Filmkorn wird als Parameter übertragen |

**Encoding-Performance:** Software-Encoding ist 50–200× langsamer als H.264. Erst Hardware-Encoder (Intel ab Gen 12, NVIDIA RTX 40, Apple M3) machen Echtzeit-Encoding praktikabel.

**Adoption 2025:** YouTube und Netflix nutzen AV1 für 4K/8K-Streams. 2024 gewann AV1 einen Emmy für technische Innovation – offene Standards können Industriestandard werden.

---

<!-- _header: '' -->
<!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->

![bg contain](./assets/av1-grammy.png)

<!--
- AV1 gewann 2024 einen Emmy für technische Innovation
- Anerkennung für offene Standards
- Zeigt: Open Source kann Industriestandard werden
-->

---

<!-- _class: lead -->

# Fragen & Diskussion

**Kontakt:** lb-czechowski@hdm-stuttgart.de
**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)

<!--
- Offene Fragen?
- Welches Thema war am überraschendsten?
- Hinweis auf Selbstlernaufgaben (nächste Folien)
-->

---

# Lizenz & Attribution

Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**

- Erlaubt Teilen & Anpassen mit Namensnennung
- Adaptionen müssen unter gleicher Lizenz geteilt werden

Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)

<!--
- Folien dürfen verwendet und angepasst werden
- Bedingung: Namensnennung und gleiche Lizenz
- Fragen zur Lizenz? → Creative Commons Website
-->

---

<!-- _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 zum Erkunden:**
- Ab welcher Quality werden Artefakte sichtbar?
- Wie viel kleiner ist WebP bei gleicher Qualität?

<!--
- Squoosh: Google-Tool zum Vergleichen von Bildformaten
- Live-Vergleich mit Schieberegler
- Ziel: Gefühl für Kompressionsraten entwickeln
- Bonus: Eigene Fotos testen
-->

---

<!-- _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
- MediaInfo zeigt alle technischen Details
- HandBrake: GUI für FFmpeg, einfacher zu bedienen
- Experiment: Gleiches Video, verschiedene Codecs vergleichen
-->