branch-coexist: 3 neue decks 223015b-2026 / 223015c-2026 / dhbw-2026 daneben main
per user-request einen branch der main-content UND rewrite-content trägt — saubere separierung statt symlink/merge-conflict. struktur: - slides/<course>/ → main-content restored, eigene assets (kein new-demo-leak) - slides/<course>-2026/ → rewrite-content, eigene assets (komplett kopiert + new demos) Makefile: COURSES += 223015b-2026 223015c-2026 dhbw-2026 mit eigenen NAME/KAPITEL/DEPLOY/KLAUSUR-konfig. Klausur für b+c=1, dhbw=leer. Deploy-paths /hdm/223015b-2026 etc. make build durchlaufen für alle 6 decks, 0 fehler. dedup: 223015c+dhbw assets identisch in beiden ordnern (kein neu-demos auf b ergänzt). 223015b 86 → 120 files in -2026 (= +34 neue eroeffner/usb-c-drei-achsen/container-vs-codec/etc).
This commit is contained in:
libretech committed
1 parent
6209f9f3a0
commit
351e3dfc23
467 files changed
+32391
-4701
No files matched your search
@@ -0,0 +1,987 @@
|
||||
---
|
||||
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: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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: RGB → Y'CbCr
|
||||
|
||||
|
||||
|
||||
**Trick:** Helligkeit von Farbe **trennen**.
|
||||
|
||||
* **Y** = Luminanz (Helligkeit)
|
||||
* **Cb** = blau-gelb-Differenz
|
||||
* **Cr** = rot-grün-Differenz
|
||||
|
||||
Auge sieht **Y scharf**, **Cb/Cr grob.** Beide werden unabhängig komprimiert.
|
||||
|
||||
<!--
|
||||
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)
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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 — die zentrale Idee
|
||||
|
||||
|
||||
|
||||
Aufeinanderfolgende Frames sind **fast gleich**. Statt jedes ganz speichern: nur **Differenz**.
|
||||
|
||||
Drei Frame-Typen:
|
||||
|
||||
* **I** (Intra) — ganzes Bild
|
||||
* **P** (Predicted) — Diff zum vorigen
|
||||
* **B** (Bidirectional) — Diff zu vorigem + nächstem
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
-->
|
||||
Reference in new issue
Block a user