uni/slides/223015b/03-speichermedien-schnittstellen.md

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

<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 :not(header),
section.erklaerung :not(footer) { 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: lead -->

# Kapitel 3
## Inhalte — Bild, Audio, Video

<!--
Längere Sitzung (ggf. 2 Termine): drei Modalitäten, drei Pipelines, drei Format-Politiken.

Anschluss an Kap 2: dort haben wir Lossy-Prinzip kennengelernt (Psychoakustik, Psychovisualität). Hier zeigen wir die konkreten Pipelines — wie genau macht JPEG/MP3/H.264 das?

Bogen:
1. Bilder (Raster vs Vektor, JPEG-Pipeline, weitere Formate)
2. Audio (MP3-Pipeline-Recap, Format-Wahl)
3. Video (Container ≠ Codec, I/P/B-Frames, H.264 vs H.265 vs AV1)
-->

---

<!-- _class: lead -->

# Drei Modalitäten, ein Prinzip

<!--
Anker im Alltag: Instagram, Spotify, YouTube. Was tun diese Plattformen?
- Instagram: zeigt Fotos (Bild)
- Spotify: spielt Musik (Audio)
- YouTube: streamt Video (Bild + Audio + Zeit)

Alle drei nutzen lossy Kompression. Alle drei nutzen Wahrnehmungs-Lücken. Aber die Pipelines sind verschieden.

Vorgriff: am Ende dieses Kapitels werdet ihr wissen, was in einer JPEG-Datei, in einer MP3-Datei und in einer MP4-Datei wirklich drinsteckt.
-->

---

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

![bg fit](./assets/demos/kap03-eroeffner.png)

<!--
Tabellarische Übersicht zum Reduktions-Hebel pro Modalität:
- Bild (12-MP-Foto): RAW 36 MB → JPEG Q90 4 MB → JPEG Q50 800 KB (Faktor ×45)
- Audio (30 s Stereo): WAV 5,3 MB → MP3 192 kbit/s 720 KB → MP3 64 kbit/s 240 KB (Faktor ×22)
- Video (30 s 4K 30fps): Roh 12 GB → H.264 25 Mbit/s 94 MB → H.265 12 Mbit/s 45 MB (Faktor ×270)

Jede Reduktion nutzt eine andere Wahrnehmungs-Lücke:
- Bild → geringere Farbschärfe (Chrominanz vs Luminanz)
- Audio → Maskierung (lauter Ton überdeckt leise)
- Video → Frame-zu-Frame-Ähnlichkeit (Inter-Frame)
-->

---

<!-- _class: lead -->

# Sub-Sektion A: Bilder

<!--
Reihenfolge:
1. Raster vs Vektor (Konzept)
2. JPEG-Pipeline (6 Schritte)
3. Andere Formate (PNG, GIF, WebP, AVIF, SVG)
4. Format-Wahl-Matrix
5. Patent-Politik (warum WebP > JPEG XL)
-->

---

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

![bg fit](./assets/demos/raster-vs-vektor.png)

<!--
Zwei fundamentale Bild-Modelle:

**Raster:** Bild = Gitter aus Pixel-Farbwerten. Jede Position fest belegt.
- Beispiele: PNG, JPEG, GIF, WebP, RAW
- Vorteil: kann Fotos darstellen (kontinuierliche Tonwerte)
- Nachteil: feste Auflösung. Beim Vergrößern wird es pixelig.

**Vektor:** Bild = mathematische Anweisungen ("Punkt 30,110 → Punkt 90,170 → Punkt 250,30, Strichbreite 14").
- Beispiele: SVG, PDF, Schriftarten, Adobe Illustrator
- Vorteil: scharf bei jeder Größe (wird neu berechnet)
- Nachteil: kann keine Fotos (keine analytischen Beschreibungen für Megapixel von Pixeln)

Anwendung: Logo → Vektor. Foto → Raster. Icon → Vektor.
-->

---

<!-- _class: klausur -->

# Raster vs. Vektor

| | Raster | Vektor |
|--|--------|--------|
| Was | Gitter aus Pixel-Werten | Mathematische Anweisungen |
| Speicher | wächst mit Auflösung | wächst mit Komplexität |
| Skalierung | pixelig beim Zoom | scharf bei jeder Größe |
| Geeignet für | Fotos, Screenshots | Logos, Icons, Schrift |
| Formate | PNG · JPEG · GIF · WebP | SVG · PDF · Schriftarten |

<!--
Klausurfähig. Geben Sie:
- ein Format zu jeder Spalte
- ein Anwendungsbeispiel zu jeder Spalte
- begründen warum Vektor bei Logos und Raster bei Fotos

Trick-Frage: kann man ein Foto in SVG speichern? Theoretisch ja (mit Millionen winziger Rechtecke), praktisch nein — wird dann viel größer als JPEG.
-->

---

<!-- _class: lead -->

# JPEG — das Foto-Workhorse seit 1992

<!--
JPEG = Joint Photographic Experts Group, Standard seit 1992.

Bis heute das dominierende Foto-Format im Web (~70 % aller Web-Bilder). Warum?
- Sehr gute Kompression bei akzeptabler Qualität
- Patentfrei seit 2017 (vorher schon weitgehend lizenzfrei)
- Universelle Unterstützung in Browsern, OS, Druck

Aber: lossy. Jede Speicherung erzeugt Verlust. Wer ein JPEG immer wieder bearbeitet und speichert, baut Artefakte auf (Generation Loss).
-->

---

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

![bg fit](./assets/demos/jpeg-pipeline.png)

<!--
JPEG-Pipeline in 6 Schritten:

1. Farbraumkonversion: RGB → Y'CbCr. Helligkeit (Y) von Farbe (Cb, Cr) trennen.
2. Chroma-Subsampling 4:2:0: Cb und Cr auf 1/4 reduziert (Auge sieht Farbdetail nicht so scharf). LOSSY.
3. 8×8-Blöcke: Bild in kleine Kacheln teilen, jeder Block einzeln behandelt.
4. DCT (Diskrete Kosinus-Transformation): jeden Block in Frequenz-Komponenten zerlegen. Häufige Helligkeitsmuster werden sichtbar.
5. Quantisierung: hohe Frequenzen (Detail) werden gerundet. HIER passiert die hauptsächliche Lossy-Reduktion. Je niedriger die Qualitätsstufe, desto aggressiver.
6. Huffman-Coding: lossless. Häufige Werte bekommen kurze Codes, seltene Werte lange Codes.

Resultat: Foto-Datei ist 10× kleiner als RAW, sieht für das Auge fast identisch aus.
-->

---

# Schritt 1: Farbraum-Konversion (RGB → Y'CbCr)

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

**Trick:** Helligkeit von Farbe **trennen**.

- **Y** (Luminanz) = wie hell ist der Pixel
- **Cb** = blau-gelb-Differenz
- **Cr** = rot-grün-Differenz

Das Auge sieht **Luminanz scharf**, **Chrominanz grob**.
Durch Trennung können beide unabhängig komprimiert werden.

<!--
Diese Trennung ist verlustfrei — mathematische Umrechnung zwischen Farbräumen.

Y'CbCr ist auch der Farbraum, in dem Fernseh- und Video-Signale übertragen werden (BT.601, BT.709). Hat historische Gründe (kompatibel mit Schwarz-Weiß-TV: Y alleine = SW-Bild).

Nach diesem Schritt: keine Reduktion, aber Vorbereitung für Schritt 2.
-->

---

# Schritt 2: Chroma-Subsampling (4:2:0)

![bg right:48% contain](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png)

**Y bleibt voll.** **Cb und Cr werden auf 1/4 reduziert** (2×2 Pixel teilen sich einen Farbwert).

- 4:4:4 = keine Reduktion
- 4:2:2 = horizontal halbiert
- **4:2:0 = JPEG-Standard, beide Richtungen halbiert**

**Lossy.** Speichermenge halbiert, sichtbarer Unterschied: null.

<!--
4:2:0-Notation kommt von alten Video-Standards. Erste Zahl = relative Y-Sample-Anzahl, zweite = Cb-Samples in Zeile 1, dritte = in Zeile 2.

Konsequenz: Bilder mit sehr feinen Farbkanten (z.B. roter Text auf grünem Hintergrund) können in 4:2:0-JPEG sichtbare Farbsäume haben. Deshalb ist JPEG für solche Inhalte schlechter als PNG.

Faustregel: 4:2:0 ist OK für Fotos. Für Text-Grafiken und Screenshots eher PNG nehmen.
-->

---

# Schritt 3 & 4: 8×8 Blöcke + DCT

Das Bild wird in **8×8-Pixel-Blöcke** zerlegt. *Jeder Block einzeln* weiterverarbeitet.

**DCT** (Diskrete Kosinus-Transformation) zerlegt jeden Block in **Frequenz-Komponenten:**

- niedrige Frequenz = grobe Helligkeitsänderungen (Hintergrund)
- hohe Frequenz = feines Detail (Kanten, Rauschen)

Beide Schritte sind **verlustfrei**. Sie bereiten Schritt 5 vor.

<!--
Warum 8×8? Trade-off:
- Größere Blöcke (z.B. 16×16): bessere Kompression, aber kostspieliger zu berechnen
- 8×8 wurde 1992 als guter Kompromiss gewählt; passt zu der damaligen Hardware

DCT-Aha:
- Ein Block, der nur eine Farbe ist → eine Frequenz-Komponente (Mittelwert)
- Ein Block mit feinen Streifen → viele hohe Frequenzen
- Die meisten realen Bildblöcke konzentrieren ihre Energie in den niedrigen Frequenzen

Pointe: nach DCT „sieht" man, was im Block wichtig ist. Schritt 5 wirft die unwichtigen hohen Frequenzen weg.
-->

---

# Schritt 5: Quantisierung — *hier* wird weggeworfen

Jeder DCT-Koeffizient wird durch einen Wert aus der **Quantisierungs-Tabelle** geteilt und gerundet.

**Niedrige Frequenzen** (wichtig): kleine Tabellen-Werte → wenig Rundung → bleiben erhalten.
**Hohe Frequenzen** (Detail): große Tabellen-Werte → starke Rundung → werden Null.

**Quality-Slider 100 → 1** ist nichts anderes als „aggressiver multiplizieren".

<!--
DCT-Koeffizienten in einem Block sehen typisch so aus:
[ 200, 50, 20,  5,  2,  1,  0,  0]
[  60, 15,  8,  3,  1,  0,  0,  0]
[  25,  8,  4,  1,  0,  0,  0,  0]
[  ...

Quantisierungs-Tabelle (Q90, ähnlich JPEG-Standard):
[  3,  2,  2,  4,  6, 10, 13, 16]
[  2,  2,  3,  4,  7, 15, 16, 14]
...

Division + Rundung:
[ 67, 25, 10,  1,  0,  0,  0,  0]
[ 30,  8,  3,  1,  0,  0,  0,  0]
[  8,  4,  1,  0,  0,  0,  0,  0]

Die hohen Frequenzen sind Null geworden. Die NULL-Sequenzen werden in Schritt 6 sehr effizient huffman-kodiert.

Bei Quality 50 oder 10 sind die Werte in der Tabelle viel höher → viel mehr Nullen → kleinere Datei, aber sichtbare Artefakte (8x8-Blöcke werden sichtbar).
-->

---

# Schritt 6: Huffman-Coding (verlustfrei)

Die quantisierten Koeffizienten sind voller **Nullen** (die hohen Frequenzen).

**Huffman:** häufige Werte (= Nullen) bekommen **kurze Codes**, seltene Werte lange Codes.

Plus **Zigzag-Scan + RLE**: lange Null-Sequenzen → ein einziges Symbol.

**Resultat:** finale JPEG-Datei. Verlustfrei aus quantisierten Werten rekonstruierbar.

<!--
Huffman-Coding ist ein klassisches lossless-Verfahren, das auf der Häufigkeitsverteilung beruht. Es bezeichnet das gleiche Prinzip wie in ZIP — also kompatibel mit Kap 2.

Zigzag: die 8×8-Koeffizienten werden in Zigzag-Reihenfolge gelesen (von niedriger zu hoher Frequenz). Dadurch landen alle Nullen am Ende → können als „Rest ist Null" kodiert werden.

Konsequenz: nach Schritt 6 ist die Pipeline fertig. Die JPEG-Datei kann gespeichert/gesendet werden. Beim Anzeigen läuft die Pipeline rückwärts.
-->

---

<!-- _class: klausur -->

# Memo: Die 6 JPEG-Schritte

| # | Schritt | Lossless / Lossy |
|---|---------|------------------|
| 1 | RGB → Y'CbCr (Farbraum) | Lossless |
| 2 | Chroma-Subsampling 4:2:0 | **Lossy** |
| 3 | 8×8 Blöcke | Lossless |
| 4 | DCT (Frequenz-Zerlegung) | Lossless |
| 5 | Quantisierung | **Lossy** (Haupt-Reduktion) |
| 6 | Huffman + Zigzag + RLE | Lossless |

Nur **2** der 6 Schritte verlieren Information.

<!--
Klausurfähig. Sechs Schritte. Reihenfolge wichtig. Lossy/Lossless-Status pro Schritt wichtig.

Eselsbrücke: „Farb-Sub-Block-DCT-Quant-Huff" → F-S-B-D-Q-H.
-->

---

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

![bg fit](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg)

<!--
Wikipedia-Bild: dieselbe Katze, fortschreitende JPEG-Kompression.

Links: kaum komprimiert (Quality ~100).
Mitte: mittlere Quality (~50).
Rechts: extreme Kompression (Quality ~10) → 8×8-Blöcke sichtbar, Farbsäume, Detail-Verlust.

Studis erkennen das aus dem Alltag:
- WhatsApp-Bilder, die durch viele Hände gingen → JPEG-Generation-Loss
- Screenshots, die als JPEG gespeichert wurden → unscharfe Schrift
- Instagram-Posts, die mehrfach re-uploaded wurden → wächsende Artefakte
-->

---

<!-- _class: lead -->

# Andere Bildformate

<!--
JPEG ist der König — aber für bestimmte Anwendungen gibt es bessere Alternativen.

Übersicht:
- PNG: lossless, mit Transparenz
- GIF: alt, animiert, max. 256 Farben
- WebP: Googles JPEG-Killer
- AVIF: AV1-basiert, noch effizienter
- SVG: vektor, skalierbar
-->

---

# Bildformate im Überblick

| Format | Typ | Loss | Transparenz | Animation | Stärke |
|--------|-----|------|------------|-----------|--------|
| **JPEG** | Raster | Lossy | ✗ | ✗ | Fotos |
| **PNG** | Raster | Lossless | ✓ | ✗ | Logos, Screenshots |
| **GIF** | Raster | Lossless | 1-bit | ✓ | Memes, Sticker |
| **WebP** | Raster | beides | ✓ | ✓ | Modern Web |
| **AVIF** | Raster | beides | ✓ | ✓ | Höchste Qualität bei kleinster Datei |
| **SVG** | Vektor | Lossless | ✓ | ✓ (mit JS/CSS) | Logos, Icons |

<!--
- PNG: ältester moderner Lossless-Standard, seit 1996 (als Patent-freier GIF-Ersatz entstanden).
- GIF: 1987, eingeschränkt auf 256 Farben, animationsfähig — daher heute der Meme-Veteran.
- WebP: Google 2010, soll JPEG ersetzen. Ist 25-35% kleiner als JPEG bei gleicher Qualität.
- AVIF: 2019, basiert auf AV1-Video-Codec. ~50% kleiner als JPEG, ~20% kleiner als WebP.
- SVG: 2001, das einzige Vektor-Format hier. Skaliert ohne Verlust.

Quality-Bewusstsein: SVG ist nicht „Konkurrenz" zu Raster-Formaten — sie lösen verschiedene Probleme.
-->

---

<!-- _class: klausur -->

# Wann welches Bildformat?

| Anwendung | Format | Warum |
|-----------|--------|-------|
| Foto im Web (Insta, News) | **JPEG** oder **WebP** | klein, Foto-optimiert |
| Foto-Archiv (RAW) | **RAW**, **TIFF**, **DNG** | nichts verlieren |
| Logo, Icon (skalierbar) | **SVG** | wird neu berechnet |
| Logo als Raster | **PNG** | Transparenz + scharfe Kanten |
| Screenshot mit Text | **PNG** | scharfe Buchstaben |
| Animiertes Sticker | **GIF** oder **WebP** | beide animierbar |
| Foto in höchster Modern-Qualität | **AVIF** oder **WebP** | bessere Kompression als JPEG |

<!--
Klausurfähig: gegeben ein Anwendungsfall, welches Format und warum?

Sub-Frage: was schief geht, wenn ich JPEG für ein Logo nehme? → unscharfe Ränder + sichtbare Artefakte.

Sub-Frage: warum nicht immer AVIF? → Browser-Support (manche ältere Browser können AVIF noch nicht), Tool-Kompatibilität, Workflow-Etablierung.
-->

---

# Patent-Politik — warum WebP, nicht JPEG XL?

**WebP** (Google, 2010): lizenzfrei. Chrome supportet von Anfang an. Heute überall.

**JPEG XL** (2021): technisch überlegen — bessere Kompression, lossless+lossy in einem Format, JPEG-kompatibel. Sollte JPEG ablösen.

**Google entfernte Chrome-Support für JPEG XL im Februar 2023.** Begründung: „nicht genug ökosystem-traction". Inoffiziell: WebP ist Google's eigenes Format.

→ **Patent-Politik schlägt technische Überlegenheit.** Wer den Browser kontrolliert, kontrolliert das Format.

<!--
Diese Geschichte zeigt: die Wahl von Bildformaten ist nicht nur technisch, sondern politisch.

JPEG XL hatte alles für sich:
- Bessere Lossy-Kompression als JPEG, WebP, AVIF
- Bessere Lossless-Kompression als PNG
- Erlaubt lossless-Konvertierung von altem JPEG (=> zukunftssicher)
- Patentfrei

Aber: Google deklarierte 2023, Chrome supportet JPEG XL nicht. Damit war das Format faktisch tot — weil >70 % aller Browser Chrome-basiert sind.

Bittersüße Lektion: technische Standards setzen sich nicht durch Verdienst durch, sondern durch Marktmacht. AVIF (auch Google) bleibt — JPEG XL nicht.

Apple supportet JPEG XL ironischerweise in macOS Sonoma + Safari 17 (2023). Ein seltener Fall, wo Apple offener ist als Google.
-->

---

<!-- _class: lead -->

# Sub-Sektion B: Audio

<!--
Audio ist kürzer als Bilder, weil wir die Grundlagen (Sampling, Bittiefe, Datenrate, Nyquist) bereits in Kap 1 hatten. Hier nur:
- Recap Sampling + Bittiefe
- MP3-Trick konkret (Maskierung)
- Bitrate-Stufen verstehen
- Format-Wahl-Matrix
-->

---

# Sampling + Bittiefe — Recap aus Kap 1

**Sampling Rate** (Hz): wie oft messen wir pro Sekunde.
**Bittiefe** (bit): wie fein jede Messung.
**Datenrate** = Sample Rate × Bittiefe × Kanäle.

**CD-Audio:** 44,1 kHz × 16 bit × 2 = **1,4 Mbit/s** → ~10 MB/Min.

**Wir wollen:** ~1 MB/Min (10× kleiner). *Wie?*

<!--
Anschluss zu Kap 1 (Nyquist): unkomprimierte Audio ist 10 MB/Min. Streaming geht aber mit 1 MB/Min. Lösung: MP3 (oder AAC, OPUS).

Diese Folie ist nur Recap. Der eigentliche Inhalt kommt nächste Folie.
-->

---

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

![bg fit](./assets/demos/psychoakustik-grafik.png)

<!--
Erinnerung aus Kap 2: Maskierung.

Ein lauter Ton (Masker) macht in seiner Frequenz-Umgebung leise Töne unhörbar.

MP3-Pipeline:
1. Audio in 32 Frequenz-Bänder unterteilen (Filterbank)
2. Psychoakustisches Modell anwenden — pro Band: was ist hörbar?
3. Quantisierung — nicht-hörbares wegwerfen
4. Huffman-Coding der Rest-Daten

Pointe: typischerweise 90 % der Daten weggeworfen, ohne dass im Alltag etwas vermisst wird.

Die Pipeline selbst ist mathematisch komplexer als JPEG (echte Filterbank statt einfacher DCT), aber das Prinzip ist gleich:
- Wahrnehmungs-Modell
- Quantisierung (lossy)
- Huffman (lossless)
-->

---

# Bitrate — der Qualitäts-Knopf

| Bitrate | Anwendung | Hörbar? |
|---------|-----------|---------|
| **64 kbit/s** | Sprachnachricht WhatsApp | dumpf, hörbar schlechter |
| **128 kbit/s** | YouTube-Audio, frühe MP3s | mittel, viele hören Unterschied |
| **192 kbit/s** | Spotify Free | gut für Alltag |
| **320 kbit/s** | Spotify Premium „sehr hoch" | praktisch CD-Qualität |
| **1 411 kbit/s** | CD (unkomprimiert) | Referenz |

**Faustregel:** je höher die Bitrate, desto mehr Detail bleibt erhalten — *aber Diminishing Returns ab ~256 kbit/s.*

<!--
Spotify-Premium-Stufen:
- Niedrig: 24 kbit/s (selten benutzt)
- Normal: 96 kbit/s
- Hoch: 160 kbit/s
- Sehr hoch: 320 kbit/s (nur Premium)

Spotify HiFi (lossless 1411 kbit/s): seit Jahren angekündigt, immer wieder verschoben.

Pointe: für die meisten Anwendungen reicht 192 kbit/s. Wer mehr will, sollte FLAC nehmen (nicht MP3).
-->

---

# Audio-Format-Landschaft

| Format | Loss | Anwendung | Bitrate |
|--------|------|-----------|---------|
| **WAV** | Lossless | Studio-Master, Wave-Editor | 1.411 kbit/s (CD) |
| **FLAC** | Lossless | Audiophile, Archiv | ~700 kbit/s (CD-Kompression) |
| **MP3** | Lossy | Universalformat, älter | 128-320 kbit/s |
| **AAC** | Lossy | Apple, YouTube, modern | 128-256 kbit/s |
| **OGG / Vorbis** | Lossy | Open-Source, Spotify (alt) | 128-320 kbit/s |
| **Opus** | Lossy | WhatsApp Call, Zoom | 6-510 kbit/s |

<!--
Wichtig:
- WAV ist nur ein Container. Inhalt ist roh PCM (oder seltener lossless-komprimiert).
- FLAC = lossless, aber komprimiert (Faktor 2-3 gegenüber WAV).
- AAC ist technisch besser als MP3 (ca. 30% kleiner bei gleicher Qualität), aber Patent-Lizenzen.
- Opus ist der moderne Open-Source-Codec für Sprache UND Musik. Variable Bitrate.
-->

---

<!-- _class: klausur -->

# Audio-Format-Wahl

| Anwendung | Format | Warum |
|-----------|--------|-------|
| Spotify-Stream | **AAC** oder **MP3 192+** | Kompression, breite Unterstützung |
| Studio-Master | **WAV** oder **FLAC** | Bit-genau erhalten |
| Sprachnachricht | **Opus** oder **AAC-LD** | für Sprache optimiert, niedrige Bitrate |
| Podcast-Distribution | **MP3 128 kbit/s** | universelle Unterstützung |
| HiFi-Audiophile | **FLAC** | lossless, kleiner als WAV |
| Archiv eigener Aufnahmen | **FLAC** oder **WAV** | nichts verlieren |

<!--
Klausurfähig: gegeben ein Anwendungsfall, welches Format?

Trick-Frage: warum nicht MP3 320 für Studio? → Lossless ist immer noch verlustfrei besser. Wer mastern will, braucht das.

Trick-Frage 2: warum nicht WAV für Spotify? → Daten-Volumen zu hoch fürs Streaming.
-->

---

<!-- _class: aufgabe -->

# Selbstlernen — Spotify-Bitrate live

Auf eurem Handy:

1. Spotify Premium-Setting auf **Niedrig (24 kbit/s)** umstellen
2. Lieblings-Track mit **Kopfhörer** anhören. Auf Höhen achten.
3. Auf **Sehr hoch (320 kbit/s)** umstellen
4. Gleicher Track. Vergleichen.

**Was fällt auf?** Welche Frequenzen verschwinden zuerst?

<!--
Pädagogisch: Studis hören selber, was der psychoakustische Codec wegwirft.

Erwartung:
- 24 kbit/s: hochfrequente Detail weg (Cymbal, „s"-Töne), Stimme klingt dumpf
- 320 kbit/s: praktisch identisch mit CD

Diskussion: für welche Hörsituation braucht ihr 320? (Studio-Kopfhörer, gute Anlage) Für welche reicht 96? (Smartphone-Lautsprecher).
-->

---

<!-- _class: lead -->

# Sub-Sektion C: Video

<!--
Video = Bild + Zeit + Audio.

Drei Konzepte zentral:
1. Container ≠ Codec (DAS Missverständnis)
2. Inter-Frame-Kompression (Frame-zu-Frame-Ähnlichkeit nutzen)
3. Codec-Landschaft (H.264, H.265, VP9, AV1) + Patent-Politik

Wir bauen auf JPEG auf — Inter-Frame nutzt JPEG-ähnliche DCT-Kompression pro Frame, plus Zeitliches.
-->

---

# Pixel × Pixel × Hz = Datenflut

**Roh-Video 4K @ 60 fps:**

```
3 840 × 2 160 Pixel × 3 Byte × 60 fps = 1,49 GB/s
```

**Pro Minute:** ~90 GB. *Pro Stunde:* ~5,3 TB.

Eine 1-TB-SSD wäre nach **~11 Minuten** voll.

→ **Ohne Kompression ist Streaming unmöglich.**

<!--
Diese Rechnung ist klausurfähig und sollte beeindrucken:
- Pixel pro Frame: 3840 × 2160 = ~8,3 Millionen
- Byte pro Pixel: 3 (RGB)
- Frame pro Sekunde: 60
- Resultat: 1,5 GB/s

Vergleich:
- Heim-Bandbreite: ~25 Mbit/s = 3 MB/s. 500× zu langsam für rohes 4K.
- 4G-Mobilfunk: ~50 Mbit/s = 6 MB/s. Immer noch 250× zu langsam.
- Netflix 4K-Stream: 25 Mbit/s. Erreicht durch Kompression. Faktor 480.

Die Kompression ist hier nicht „nice to have" — sie ist die Voraussetzung, dass es Video-Streaming überhaupt gibt.
-->

---

<!-- _class: klausur -->

# Container ≠ Codec

![bg right:40% contain](./assets/container-codec-diagram.png)

**Container** = die *Verpackung*: hält Video-Spur, Audio-Spur, Untertitel, Metadaten zusammen.
*Beispiele:* MP4, MKV, WebM, AVI

**Codec** = der *Komprimierer*: wie wird Bild/Audio gespeichert?
*Beispiele:* H.264, H.265, AV1, VP9 (Video) · AAC, MP3, Opus (Audio)

**Eine `.mp4`-Datei kann verschiedene Codecs enthalten.**

<!--
Das ist DER zentrale Missverständnis-Punkt bei Video. Studis denken oft, „MP4" oder „MKV" sei das Format des Videos. Stimmt nicht. Es ist nur die Hülle.

Konkretes Beispiel: zwei `.mp4`-Dateien:
- A: H.264-Video + AAC-Audio
- B: H.265-Video + Opus-Audio

Beide haben die Endung .mp4. Aber A spielt überall, B braucht moderne Player.

Tool: `mediainfo <datei>` zeigt Container UND Codec.

Klausurfähig.
-->

---

# Was ist in einem Container?

```
MP4-Container
├── Video-Spur (H.264, codec: avc1)
├── Audio-Spur (AAC, codec: mp4a)
├── Untertitel-Spur (TTML, optional)
└── Metadaten (Titel, Erstellungsdatum, Bitrate, GOP-Struktur, ...)
```

Container regelt:
- **Sync** zwischen Spuren (Audio passt zum Bild)
- **Seeking** (Springen im Video)
- **Streaming-Sicherheit** (Header früh genug)

<!--
Container vs Codec:
- Container = Datei-Format (.mp4, .mkv, .webm)
- Codec = Algorithmus (H.264, H.265, AV1)

Vergleich aus dem Alltag:
- Container ≈ Buchdeckel (Hardcover, Paperback, E-Book)
- Codec ≈ Sprache des Texts (Englisch, Deutsch, übersetzt)

Ein und das selbe Buch (= Video) kann in verschiedenen Buchdeckeln (Containern) und verschiedenen Sprachen (Codecs) existieren.

Konkrete Tools:
- ffmpeg: kann Container und Codec wechseln
- mediainfo: zeigt was in einer Video-Datei drin ist
- HandBrake: GUI für Encoding
-->

---

# Inter-Frame-Kompression — die zentrale Idee

![bg right:42% contain](./assets/iframe-pframe-diagram.png)

Aufeinanderfolgende Frames sehen sich **sehr ähnlich** (Kamera bewegt sich kaum, Person redet — Hintergrund bleibt fast gleich).

**Statt jedes Frame komplett zu speichern**, speichere nur die *Differenz* zum vorigen.

Drei Frame-Typen:
- **I-Frame** (Intra): ganzes Bild als JPEG-ähnliches Standalone
- **P-Frame** (Predicted): Differenz zum vorigen Frame
- **B-Frame** (Bidirectional): Differenz zu vorigem UND nächstem Frame

<!--
Inter-Frame ist DER Trick, der Video-Kompression überhaupt möglich macht.

Ohne Inter-Frame wäre 4K-Video ~480× kleiner als roh (nur durch Intra-Kompression). Mit Inter-Frame: ~10.000× kleiner. Das ist Streaming-tauglich.

GOP (Group of Pictures): typische Anordnung
- IBBPBBPBBPBBP...IBBPBBP...
- Alle 1-3 Sekunden ein I-Frame (Seeking-Anker)
- Dazwischen P- und B-Frames

B-Frames sind effizienter als P-Frames (haben zwei Vorlagen), aber teurer zu enkodieren.
-->

---

<!-- _class: klausur -->

# I, P, B — Frame-Typen

| Typ | Vollname | Was drin | Größe |
|-----|----------|----------|-------|
| **I** | Intra-coded | Komplettes Bild (wie JPEG) | groß |
| **P** | Predicted | „Was hat sich seit voriges I/P geändert" | mittel |
| **B** | Bidirectional | „Was zwischen vorigem und nächstem I/P" | klein |

Typische GOP: `I B B P B B P B B P B B I ...` (alle 1–3 Sekunden ein I-Frame).

<!--
Klausurfähig: was sind I/P/B-Frames? Welche ist die größte? Warum brauchen wir I-Frames trotzdem (Seeking, Stream-Start, Fehlerresistenz)?

GOP = Group of Pictures.

I-Frame als Seeking-Anker:
- Wenn man im Video an einer Stelle springt, kann der Player nur an I-Frames anfangen
- Zwischen I-Frames muss Player VOM letzten I-Frame ab dekodieren bis zur Spring-Stelle

Daher: I-Frames sollten nicht zu selten sein (sonst langsames Seeking), aber auch nicht zu häufig (sonst weniger Kompression).
-->

---

# Motion Compensation

Ein Block aus dem vorigen Frame wird **verschoben** — nicht neu kodiert.

P-Frame speichert:
1. Bewegungsvektor (z.B. „Block A: +5 Pixel rechts, +2 Pixel runter")
2. Differenz zum verschobenen Block

**Resultat:** Auto-Fahrt vor stehender Kamera → P-Frames mini-klein.

<!--
Motion Compensation ist der eigentliche „magic move" der Video-Kompression.

Bei einer Kamerafahrt (Schwenk) ist der Großteil des Bildes nur „verschoben". Der Codec sucht für jeden 16×16- oder 32×32-Block im neuen Frame den am besten passenden Block in einem Referenz-Frame und speichert nur:
- Position dieses Referenz-Blocks
- Differenz (das, was sich tatsächlich geändert hat)

Für statische Szenen mit reden den Personen: P-Frames sind oft ~5 % der I-Frame-Größe.

Encoding ist asymmetrisch: Encoder muss diese Block-Suche durchführen → teuer. Decoder bekommt nur die fertigen Vektoren → billig. Deshalb ist Video-Encoding viel langsamer als -Decoding.
-->

---

<!-- _class: lead -->

# Die Codec-Landschaft

<!--
H.264 → H.265 → AV1 → ?

Vier Generationen:
- H.264 (2003): der dominierende Codec, überall, lizenzpflichtig aber gnädig
- H.265 (2013): 50% effizienter, aber Patent-Chaos (mehrere Patent-Pools)
- VP9 (2013): Google-Antwort, lizenzfrei
- AV1 (2018): Industrie-Allianz, lizenzfrei, beste Kompression

Politik schlägt Technik. Ein guter Codec, der teuer ist, setzt sich nicht durch — siehe H.265.
-->

---

# H.264 / AVC — der Workhorse

**2003** • dominierender Video-Codec seit Smartphone-Ära.

Wo überall verwendet:
- YouTube (Hauptcodec)
- Zoom, Teams, Meet
- Netflix (HD-Streams)
- Smartphones (alle iOS-Aufnahmen, viele Android)

Patente: MPEG-LA-Pool. Lizenzkosten **moderat**, viele Hersteller decken die Kosten in der Hardware ab.

<!--
H.264 hat sich durchgesetzt weil:
- Technisch deutlich besser als sein Vorgänger (MPEG-2)
- Hardware-Decoder seit ~2010 in jedem Smartphone-Chip
- Patente sind kostspielig, aber überschaubar (vergleichbar mit JPEG/MP3 in den 90ern)

Trotz Alter (~22 Jahre) immer noch der Standard. Effizienter sind H.265 und AV1, aber Kompatibilität und Patent-Klarheit halten H.264 lebendig.
-->

---

# H.265 / HEVC — Patent-Chaos

**2013** • technisch ~50 % effizienter als H.264.

**Aber:** drei separate Patent-Pools, intransparente Lizenzkosten.

Resultat:
- **Apple** macht alles in H.265 (HEIC-Fotos, iOS-Video) — bezahlt Lizenzen
- **YouTube, Netflix** verzichten weitgehend — zu teuer + risikoreich
- **Industrie-Reaktion:** Allianz für Open Media (AOMedia) gegründet, baut AV1

<!--
H.265 ist der Lehrbuch-Fall für „technisch überlegen, kommerziell gescheitert".

Drei Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) wollten alle separat Lizenzgebühren. Niemand wusste, was das Gesamt-Paket kostet. Software-Hersteller (Browser, Encoder) konnten kein realistisches Budget machen.

YouTube und Netflix haben deshalb H.265 für ihre Streaming-Operationen meiden lassen. Investierten stattdessen in VP9 (Google) und AV1 (AOMedia).

Apple ist mit HEIC ein Sonderfall: Apple hat genug Kapital, um die Lizenzen aller drei Pools zu zahlen, und nutzt H.265 für die kameraseitige Aufnahme.

Pointe: ein guter Codec ohne klare Lizenz-Situation ist tot für die Industrie.
-->

---

# VP9 + AV1 — die offene Antwort

**VP9** (Google, 2013): lizenzfrei, ähnlich effizient wie H.265.
- YouTube nutzt es für 4K-Streams (Chrome, Firefox).

**AV1** (Alliance for Open Media, 2018): Konsortium aus Google, Mozilla, Netflix, Amazon, Apple, ARM, Microsoft, Cisco, Intel, NVIDIA...
- **Lizenzfrei.** **30 % effizienter als H.265.**
- Hardware-Decoder seit ~2021 verfügbar (M1, Snapdragon 888+).
- YouTube, Netflix, Twitch streamen schon AV1.

<!--
AV1 ist die Industrie-Antwort auf das H.265-Patent-Desaster.

Bei AV1 standen die wichtigsten Internet-Player zusammen und sagten: „wir bauen einen Codec, der allen gehört, lizenzfrei ist und mindestens so gut wie H.265". 2018 war der Standard fertig.

Heute:
- YouTube streamt 4K viel in AV1
- Netflix streamt AV1 wo Decoder verfügbar
- Twitch ebenfalls
- Chrome, Firefox, Edge supportet AV1 nativ
- Safari supportet seit macOS 13/Apple-M3-Chip

Hardware ist der Engpass: AV1 ist rechenintensiver zu enkodieren als H.264. Aber für die Studis, die einfach Videos schauen, ist das nicht relevant.

Pointe: politisch gewinnt der „offene" Codec, wenn die Industrie es will. Bei AV1 hat sie es gewollt.
-->

---

<!-- _class: klausur -->

# Patent vs. Open — warum AV1?

| Codec | Effizienz | Patent | Adoption (2026) |
|-------|-----------|--------|-----------------|
| H.264 | Baseline | Lizenz (MPEG-LA) | ~80 % aller Videos |
| H.265 | +50 % | 3 Patent-Pools, chaotisch | nur Apple |
| VP9 | ~H.265 | lizenzfrei (Google) | YouTube 4K |
| **AV1** | **+30 % über H.265** | **lizenzfrei (Allianz)** | **YouTube, Netflix, Twitch** |

**Die Lektion:** technisch beste Lösung gewinnt nicht. *Lizenz-klare* beste Lösung gewinnt.

<!--
Klausurfähig: warum hat AV1 H.265 abgelöst, wenn beide ähnlich effizient sind?

Antwort: Patent-Politik. H.265 hat drei Patent-Pools, AV1 ist lizenzfrei. Industrie-Konsortium hat AV1 finanziert, weil sie nie wieder einem MPEG-LA-Pool ausgeliefert sein wollten.

Sub-Frage: warum nicht VP9? → AV1 ist effizienter (~30 %), und alle wichtigen Player stehen dahinter (statt nur Google).
-->

---

# 4K-Stream vs. Heim-Bandbreite

| Auflösung | Bitrate (H.265/AV1) | Heim-Bandbreite nötig |
|-----------|---------------------|----------------------|
| 480p (SD) | 1 Mbit/s | jeder Anschluss |
| 720p (HD) | 3 Mbit/s | DSL ausreichend |
| 1080p (Full HD) | 8 Mbit/s | DSL-25 + |
| **4K (UHD)** | **25 Mbit/s** | **Glasfaser oder Kabel** |
| 4K HDR | 35 Mbit/s | Kabel-Premium |
| 8K | ~100 Mbit/s | Glasfaser-200 |

**Spotify-Audio dagegen:** Highest = 320 kbit/s = 0,3 Mbit/s. *80× weniger als ein 4K-Stream.*

<!--
Diese Folie zeigt: Video ist die mit Abstand bandbreitenhungrigste Anwendung im Internet.

Konkret in DE (2026 Stand):
- VDSL 50 Mbit/s ist Standard → reicht für 1080p, gerade so für 4K
- Glasfaser 250 Mbit/s in Großstädten → 4K kein Problem
- Mobilfunk 5G ~100 Mbit/s → 4K möglich

Konsequenz: ein 4K-Netflix-Stream allein nutzt einen typischen 50-Mbit-Anschluss zur Hälfte. Wenn der Mitbewohner auch streamt, wird's eng.

Anschluss zum nächsten Kapitel (Kap 4): „Wie kommen die Daten überhaupt zu meinem Gerät?" → Speichermedien und Schnittstellen.
-->

---

<!-- _class: aufgabe -->

# Selbstlernen — drei Übungen

**Bild:**
[Squoosh.app](https://squoosh.app) öffnen. Eigenes Foto in JPEG vs WebP vs AVIF konvertieren. Größe + Qualität vergleichen.

**Audio:**
Spotify Premium-Bitrate von 24 auf 320 kbit/s wechseln. Lieblings-Track anhören. Was fällt auf?

**Video:**
`mediainfo` (CLI oder GUI) auf eine eigene Video-Datei. Welcher Container? Welcher Codec? Welche Bitrate?

<!--
Drei Übungen, eine pro Modalität. Jede sollte ~5-10 Min dauern.

Tool-Empfehlungen:
- Squoosh.app (Browser, kein Install) — Google's Foto-Komprimierer
- mediainfo: brew install mediainfo / sudo apt install mediainfo
- Spotify: integriert

Pädagogisches Ziel: Studis sollen das Gelernte am eigenen Material durchspielen.
-->

---

# Zusammenfassung

**Drei Modalitäten, ein Prinzip:** Wahrnehmungs-Lücken als Hebel.

| | **Bild** | **Audio** | **Video** |
|--|----------|-----------|-----------|
| Lossy-Trick | Chroma-Subsampling + DCT-Quantisierung | Maskierung + Hörschwelle | Inter-Frame + JPEG-pro-Frame |
| Standardformat | JPEG | MP3/AAC | H.264 / AV1 |
| Reduktion | ~10× | ~10× | ~100× |
| Format-Politik | WebP > JPEG XL (Google) | MP3-Patent → AAC | H.265-Chaos → AV1 |

**In Kap 4** schauen wir uns an, *wie* diese Daten zu eurem Gerät kommen — und welche Schnittstelle dabei der Engpass ist.

<!--
Recap:

Drei Modalitäten:
- BILD: Raster vs Vektor. JPEG-Pipeline 6 Schritte (Farbraum, Chroma-Sub, Blöcke, DCT, Quant, Huffman). PNG/GIF/WebP/AVIF/SVG-Landschaft. Patent-Politik (WebP vs JPEG XL).
- AUDIO: Sampling+Bittiefe-Recap. MP3-Maskierung. Bitrate-Stufen 128/192/320. Format-Landschaft (WAV/FLAC/MP3/AAC/Opus).
- VIDEO: Container ≠ Codec. I/P/B-Frames. Motion Compensation. Codec-Landschaft (H.264/H.265/VP9/AV1). AV1-Patent-Politik.

Großes Thema dahinter: Wahrnehmung als Hebel. Was wir nicht sehen/hören → wegwerfen. Das ist die ganze Magie hinter Lossy.

Anschluss Kap 4: jetzt wissen wir, WAS in einer JPEG/MP3/MP4-Datei drin ist. Jetzt: wie kommt es zu uns? Speicher + Schnittstellen.
-->