1023 lines
25 KiB
Markdown
1023 lines
25 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||
footer: "Michael Czechowski – HdM Stuttgart"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege - Teil 2
|
||
---
|
||
|
||
<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: #1a1a2e;
|
||
color: #5fb3e4;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
}
|
||
a {
|
||
color: var(--color-highlight);
|
||
}
|
||
section.klausur {
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# 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/)
|
||
|
||
<!--
|
||
## Kontext
|
||
Teil 2 der Vorlesungsreihe. Nachdem wir in Termin 1 Grundlagen (Physisch/Analog/Digital, Text, Audio) behandelt haben, fokussieren wir uns jetzt auf **Bild und Video** - die datenintensivsten Medientypen.
|
||
|
||
## Kernaussagen
|
||
1. Bilder und Videos sind um Größenordnungen komplexer als Audio (2D/3D statt 1D).
|
||
2. Psychovisuelle Kompression nutzt die Schwächen des menschlichen Auges.
|
||
3. Video-Kompression ist essentiell für Streaming, Social Media, Cloud.
|
||
|
||
## Leitfrage
|
||
Wie schaffen es YouTube, Netflix, Instagram trotz 4K-Video zu funktionieren?
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Bild- & Videoformate
|
||
|
||
<!--
|
||
## Überblick
|
||
**I. Grundlagen Digitaler Bilder** (Raster vs. Vektor)
|
||
**II. Psychovisuelle Kompression** (Schwächen des Auges)
|
||
**III. JPEG** (Der Bildkompressionsstandard)
|
||
**IV. Andere Bildformate** (PNG, GIF, WebP, AVIF)
|
||
**V. Instagram-Problem** (Re-Kompression)
|
||
**VI. Video** (Container, Codecs, Kompression)
|
||
**VII. Kritische Perspektive** (Deepfakes & Manipulation)
|
||
-->
|
||
|
||
---
|
||
|
||
# Rückblick: Physisch → Analog → Digital
|
||
|
||
**Bei Bildern:**
|
||
|
||
- **Physisch**: Lichtwellen (elektromagnetisches Spektrum, 380-750 nm)
|
||
- **Analog**: Film (Silberhalogenide reagieren auf Licht, kontinuierlich)
|
||
- **Digital**: Kamera-Sensor (Photodioden → A/D-Wandler, diskret)
|
||
|
||
→ **Moderne Kameras überspringen analog komplett!**
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Alte Film-Kameras: Licht → chemische Reaktion (analog) → später digitalisiert.
|
||
2. Moderne DSLRs/Smartphones: Licht → CCD/CMOS-Sensor → direkt digital (on-chip A/D-Wandlung).
|
||
3. Vorteil Digital: Kein analoges Rauschen, kein Generationsverlust, sofortige Vorschau.
|
||
|
||
## Vertiefung
|
||
Kodak entwickelte 1975 erste Digitalkamera (0,01 Megapixel, 23 Sekunden/Foto). 2000er: Digital überholte Film komplett.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# I. Grundlagen Digitaler Bilder
|
||
|
||
---
|
||
|
||
# Was ist ein digitales Bild?
|
||
|
||
**Rastergrafik (Bitmap):** Matrix aus Pixeln
|
||
|
||
Jedes Pixel = 1 Farbwert (z.B. RGB)
|
||
|
||
**Beispiel 4×4 Pixel Bild:**
|
||
```
|
||
R G B W
|
||
G B W R
|
||
B W R G
|
||
W R G B
|
||
```
|
||
|
||
**Auflösung:** Pixel-Anzahl bestimmt Detailgrad
|
||
**1920×1080 (Full HD):** 2.073.600 Pixel
|
||
**3840×2160 (4K):** 8.294.400 Pixel (4× mehr!)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Pixel = Picture Element (kleinste Einheit).
|
||
2. Mehr Pixel = mehr Detail **aber** auch mehr Daten.
|
||
3. Ein 4K-Bild hat 4× mehr Pixel als Full HD → 4× größere Datei (unkomprimiert).
|
||
|
||
## Berechnung
|
||
Full HD: 1920 × 1080 × 3 Bytes (RGB) = 6,22 MB
|
||
4K: 3840 × 2160 × 3 Bytes = 24,88 MB
|
||
-->
|
||
|
||
---
|
||
|
||
# Rastergrafiken: Das Problem der Skalierung
|
||
|
||
**Problem:** Pixelbilder verlieren Qualität beim Vergrößern
|
||
|
||
**Beispiel:** 100×100 Pixel Logo
|
||
|
||
- Anzeige in 100×100: perfekt
|
||
- Anzeige in 1000×1000: **verpixelt** (Interpolation kann nicht Details erfinden)
|
||
|
||
→ **Lösung:** Für verschiedene Größen verschiedene Versionen speichern
|
||
Oder: Vektorgrafiken nutzen
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Skalierung nach oben = Interpolation (Algorithmus rät, was dazwischen ist).
|
||
2. Gängige Interpolation: Bilinear (schnell, akzeptabel), Bicubic (langsamer, besser), Lanczos (noch besser).
|
||
3. Aber: Keine Interpolation kann verlorene Details zurückbringen.
|
||
|
||
## Beispiel
|
||
Retina-Displays: Brauchen 2× Auflösung → Websites liefern @2x Bilder für hochauflösende Screens.
|
||
-->
|
||
|
||
---
|
||
|
||
# Vektorgrafiken
|
||
|
||
**Prinzip:** Mathematische Beschreibung statt Pixel
|
||
|
||
**Beispiel Kreis:**
|
||
Raster: 1000×1000 Pixel gespeichert
|
||
Vektor: "Kreis bei (500,500), Radius 200, Farbe Rot"
|
||
|
||
**Vorteile:**
|
||
- Unbegrenzt skalierbar (verlustfrei)
|
||
- Kleine Dateigröße (nur Gleichungen)
|
||
|
||
**Nachteile:**
|
||
- Nur für geometrische Formen geeignet
|
||
- Fotos unmöglich als Vektor
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. SVG (Scalable Vector Graphics) = Standard für Web-Vektorgrafiken.
|
||
2. Anwendung: Logos, Icons, Illustrationen, Infografiken.
|
||
3. Adobe Illustrator, Inkscape = Vektor-Tools.
|
||
|
||
## Beispiel
|
||
Google Material Icons: Geliefert als SVG → perfekt auf jedem Screen (Smartphone bis 8K-Monitor).
|
||
-->
|
||
|
||
---
|
||
|
||
# Raster- und Vektorgrafiken: Vergleich
|
||
|
||
| Eigenschaft | Rastergrafik | Vektorgrafik |
|
||
|-------------|--------------|--------------|
|
||
| **Speicherung** | Pixel-Matrix | Mathematische Formeln |
|
||
| **Skalierung** | Verlustbehaftet (Interpolation) | Verlustfrei (neu berechnet) |
|
||
| **Dateigröße** | Groß (abhängig von Auflösung) | Klein (nur Gleichungen) |
|
||
| **Anwendung** | Fotos, Screenshots | Logos, Icons, Illustrationen |
|
||
| **Formate** | PNG, JPEG, GIF | SVG, AI, EPS, PDF (Vektor-Modus) |
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
Faustregel: Foto → Raster, Logo → Vektor.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# II. Psychovisuelle Kompression
|
||
## Die Schwächen des Auges nutzen
|
||
|
||
---
|
||
|
||
# Die Schwächen des Auges
|
||
|
||
**Menschliches Sehen ist nicht gleichmäßig:**
|
||
|
||
1. **Helligkeitsempfindlichkeit > Farbempfindlichkeit**
|
||
Wir sehen Graustufen schärfer als Farbnuancen
|
||
|
||
2. **Räumliche Frequenzen:**
|
||
Grobe Strukturen wichtiger als feine Details
|
||
|
||
3. **Foveales Sehen:**
|
||
Nur Zentrum des Blickfelds ist scharf (peripher unscharf)
|
||
|
||
→ **Chroma Subsampling, DCT, Quantisierung** nutzen das aus
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen) als für Farbe (Zapfen).
|
||
2. Peripheres Sehen: Bewegung wird erkannt, Details nicht.
|
||
3. JPEG, H.264, etc. codieren Helligkeit (Luma) mit höherer Auflösung als Farbe (Chroma).
|
||
|
||
## Vertiefung
|
||
YCbCr-Farbraum: Y = Luma (Helligkeit), Cb/Cr = Chroma (Farbdifferenzen). Erlaubt separate Behandlung von Helligkeit und Farbe.
|
||
-->
|
||
|
||
---
|
||
|
||
# Chroma Subsampling
|
||
|
||
**Prinzip:** Farbe mit niedrigerer Auflösung speichern als Helligkeit
|
||
|
||
**Notation:** 4:2:0, 4:2:2, 4:4:4
|
||
|
||
**4:4:4** – Volle Auflösung (keine Subsampling)
|
||
**4:2:2** – Horizontale Halbierung der Chroma
|
||
**4:2:0** – Horizontale **und** vertikale Halbierung
|
||
|
||
**Beispiel 4:2:0:**
|
||
4 Pixel Helligkeit → 1 Pixel Farbe
|
||
= **75% weniger Farbdaten, kaum sichtbar!**
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. 4:2:0 Standard für Web, Streaming, YouTube (JPEG, H.264).
|
||
2. 4:2:2 für professionelles Video (Broadcasting, Color Grading).
|
||
3. 4:4:4 nur für spezielle Anwendungen (Grafiken mit Text, medizinische Bildgebung).
|
||
|
||
## Berechnung
|
||
4:4:4: 100% Luma + 100% Chroma = 3 Bytes/Pixel
|
||
4:2:0: 100% Luma + 25% Chroma = 1,5 Bytes/Pixel → 50% Reduktion
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# III. JPEG: Der Bildkompressionsstandard
|
||
|
||
---
|
||
|
||
# JPEG: Sechs Schritte der Kompression
|
||
|
||
**JPEG = Joint Photographic Experts Group (1992)**
|
||
|
||
**Verlustbehaftete Kompression in 6 Schritten:**
|
||
|
||
1. **Farbraum-Konvertierung** (RGB → YCbCr)
|
||
2. **Chroma Subsampling** (4:2:0)
|
||
3. **DCT** (Discrete Cosine Transform)
|
||
4. **Quantisierung** (Hier entsteht Verlust!)
|
||
5. **Zigzag-Scan & RLE**
|
||
6. **Huffman-Coding**
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. JPEG ist komplex, aber jeder Schritt hat klaren Zweck.
|
||
2. Verlust entsteht nur bei Quantisierung (Schritt 4).
|
||
3. Restliche Schritte sind Vorbereitung oder verlustfreie Kompression.
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG: Schritt 1 – Farbraum wechseln
|
||
|
||
**RGB → YCbCr**
|
||
|
||
- **Y** = Luma (Helligkeit)
|
||
- **Cb** = Blau-Differenz
|
||
- **Cr** = Rot-Differenz
|
||
|
||
**Warum?**
|
||
Erlaubt Chroma Subsampling (Farbe weniger auflösen)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
YCbCr separiert Helligkeit von Farbe → Kompression kann beide unterschiedlich behandeln.
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG: Schritt 2 – Chroma Subsampling
|
||
|
||
**4:2:0 Standard:**
|
||
|
||
Aus 4 Pixeln wird:
|
||
- 4 Luma-Werte (Y)
|
||
- 1 Cb-Wert
|
||
- 1 Cr-Wert
|
||
|
||
**Resultat:** 50% Datenreduktion, kaum sichtbar
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
Dieser Schritt allein spart massiv Daten, ohne merklichen Qualitätsverlust.
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG: Schritt 3 – DCT
|
||
|
||
**Discrete Cosine Transform:**
|
||
Bild in 8×8 Pixel Blöcke teilen
|
||
Jeder Block → Frequenzbereich transformieren
|
||
|
||
**Ergebnis:**
|
||
Niedrige Frequenzen (große Flächen) → hohe Werte
|
||
Hohe Frequenzen (feine Details) → niedrige Werte
|
||
|
||
→ **Vorbereitung für Quantisierung**
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. DCT ähnlich wie FFT, aber für 2D-Bilder optimiert.
|
||
2. Niedrige Frequenzen = wichtig (grobe Struktur), Hohe Frequenzen = weniger wichtig (feine Details).
|
||
3. DCT selbst ist verlustfrei (perfekt reversibel).
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG: Schritt 4 – Quantisierung
|
||
|
||
**Hier entsteht der Verlust!**
|
||
|
||
**Prinzip:** Hohe Frequenzen stark reduzieren
|
||
|
||
Quantisierungstabelle teilt DCT-Koeffizienten:
|
||
- Niedrige Frequenzen: Division durch kleine Zahl (wenig Verlust)
|
||
- Hohe Frequenzen: Division durch große Zahl (starker Verlust)
|
||
|
||
**JPEG-Qualität (0-100):**
|
||
100 = sanfte Quantisierung (große Datei, hohe Qualität)
|
||
10 = aggressive Quantisierung (kleine Datei, Artefakte)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Quantisierung = kontrollierter Informationsverlust.
|
||
2. "JPEG-Qualität" Slider steuert Quantisierungstabelle.
|
||
3. Irreversibel: Einmal quantisiert, kann man Original nicht wiederherstellen.
|
||
|
||
## Beispiel
|
||
Hohe Frequenz-Koeffizient: 127
|
||
Quantisierungswert: 50
|
||
Resultat: 127 / 50 = 2,54 → gerundet 3
|
||
Beim Dekodieren: 3 × 50 = 150 (nicht 127!) → Fehler = 23
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG: Schritt 5 – Zigzag & RLE
|
||
|
||
**Zigzag-Scan:**
|
||
8×8 Block in 1D-Array umwandeln (niedrige Frequenzen zuerst)
|
||
|
||
**Run-Length Encoding (RLE):**
|
||
Viele Nullen (hohe Frequenzen wurden stark quantisiert)
|
||
→ `0 0 0 0 0 0 0 5` wird zu `7×0, 5`
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
Zigzag ordnet Daten so, dass RLE effizient wird (viele aufeinanderfolgende Nullen).
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG: Schritt 6 – Huffman-Coding
|
||
|
||
**Verlustfreie Kompression** (wie ZIP)
|
||
|
||
H<EFBFBD>ufige Werte → kurze Codes
|
||
Seltene Werte → lange Codes
|
||
|
||
**Beispiel:**
|
||
`0` (sehr häufig) → `1` (1 Bit)
|
||
`127` (selten) → `11001111` (8 Bit)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
Huffman ist verlustfrei und nutzt Häufigkeitsverteilung. Zusammen mit RLE finale Dateigröße deutlich kleiner.
|
||
-->
|
||
|
||
---
|
||
|
||
# Grenzen der Kompression: JPEG-Artefakte
|
||
|
||
**Bei zu hoher Kompression (niedrige Qualität):**
|
||
|
||
1. **Blocking:** 8×8 Pixel Blöcke sichtbar
|
||
2. **Color Bleeding:** Farbränder verschwimmen
|
||
3. **Ringing:** Halos um scharfe Kanten
|
||
4. **Mosquito Noise:** Flimmern um Kanten in Video
|
||
|
||
**Faustregel:**
|
||
JPEG-Qualität < 70: Artefakte sichtbar
|
||
JPEG-Qualität 85-95: Sweet Spot (kaum Verlust, gute Kompression)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Artefakte entstehen durch zu starke Quantisierung.
|
||
2. Für Web: 85% Qualität meist optimal.
|
||
3. Mehrfache JPEG-Kompression (Re-Encoding) verschlechtert stark (Generationsverlust).
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# IV. Andere Bildformate
|
||
|
||
---
|
||
|
||
# PNG: Verlustfrei mit Transparenz
|
||
|
||
**PNG = Portable Network Graphics (1996)**
|
||
|
||
**Eigenschaften:**
|
||
- Verlustfreie Kompression (Deflate-Algorithmus, wie ZIP)
|
||
- **Alpha-Kanal:** Transparenz (0 = durchsichtig, 255 = undurchsichtig)
|
||
- Paletten-Modus (8-bit, 256 Farben) oder True Color (24/32-bit)
|
||
|
||
**Anwendung:**
|
||
Logos, Screenshots, Grafiken mit Text, Transparenz
|
||
|
||
**Nachteil:**
|
||
Größer als JPEG für Fotos (keine Psychovisuelle Kompression)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. PNG wurde als GIF-Ersatz entwickelt (GIF hatte Patentprobleme).
|
||
2. Keine Qualitätsverlust-Slider (immer verlustfrei).
|
||
3. Kompression hängt ab von Bildinhalt (strukturierte Grafiken → gut, Fotos → schlecht).
|
||
-->
|
||
|
||
---
|
||
|
||
# GIF: Der Meme-Veteran
|
||
|
||
**GIF = Graphics Interchange Format (1987)**
|
||
|
||
**Eigenschaften:**
|
||
- **256 Farben** (8-bit Palette)
|
||
- **Animation** (Frame-basiert)
|
||
- LZW-Kompression (verlustfrei)
|
||
|
||
**Anwendung:**
|
||
Memes, einfache Animationen
|
||
|
||
**Nachteil:**
|
||
Nur 256 Farben → Fotos sehen schlecht aus
|
||
Ineffizient für Video (besser: MP4, WebM)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. GIF dominierte Web-Animationen 1990er-2000er (keine Alternative).
|
||
2. Heute: MP4/WebM besser für Animationen (kleinere Datei, bessere Qualität).
|
||
3. Aber: GIF bleibt in Meme-Kultur (einfach, universell unterstützt).
|
||
|
||
## Vertiefung
|
||
GIF-Patente (Unisys LZW) expirierten 2003 → jetzt patent-frei.
|
||
-->
|
||
|
||
---
|
||
|
||
# WebP & AVIF: Moderne Alternativen
|
||
|
||
**WebP (Google, 2010):**
|
||
- Verlustfrei **und** verlustbehaftet
|
||
- ~30% kleiner als JPEG bei gleicher Qualität
|
||
- Transparenz + Animation
|
||
|
||
**AVIF (AOMedia, 2019):**
|
||
- Basiert auf AV1-Video-Codec
|
||
- ~50% kleiner als JPEG
|
||
- Bessere Qualität, aber langsamer zu encodieren
|
||
|
||
**Problem:** Browser-Support
|
||
WebP: >95% (gut)
|
||
AVIF: ~85% (wachsend)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. WebP: Guter Kompromiss (Qualität, Größe, Support).
|
||
2. AVIF: Zukunft, aber noch nicht universell (Safari erst ab 2021).
|
||
3. Strategie: Moderne Formate + JPEG/PNG Fallback.
|
||
|
||
## Beispiel
|
||
```html
|
||
<picture>
|
||
<source srcset="image.avif" type="image/avif">
|
||
<source srcset="image.webp" type="image/webp">
|
||
<img src="image.jpg" alt="Fallback">
|
||
</picture>
|
||
```
|
||
-->
|
||
|
||
---
|
||
|
||
# Formatwahl in der Praxis
|
||
|
||
| Anwendung | Format | Warum? |
|
||
|-----------|--------|--------|
|
||
| **Foto (Web)** | JPEG/WebP | Verlustbehaftet OK, kleine Datei |
|
||
| **Logo** | SVG/PNG | Vektor (SVG) oder Transparenz (PNG) |
|
||
| **Screenshot** | PNG | Verlustfrei, Text lesbar |
|
||
| **Meme/Animation** | GIF/MP4 | GIF für Kompatibilität, MP4 für Effizienz |
|
||
| **Druck (CMYK)** | TIFF/PDF | Verlustfrei, CMYK-Farbraum |
|
||
| **Archivierung** | TIFF/DNG | Unkomprimiert oder verlustfrei |
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
Trade-off-Entscheidung: Qualität vs. Dateigröße vs. Kompatibilität vs. Features (Transparenz, Animation).
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# V. Warum Instagram eure Fotos "ruiniert"
|
||
|
||
---
|
||
|
||
# Social Media & Re-Kompression
|
||
|
||
**Problem:**
|
||
Instagram, Facebook, Twitter re-encodieren **alle** Uploads
|
||
|
||
**Warum?**
|
||
- Speicherkosten (Milliarden Bilder)
|
||
- Bandbreite (schnellere Ladezeiten)
|
||
- Einheitlichkeit (verschiedene Geräte)
|
||
|
||
**Konsequenz:**
|
||
Upload PNG/JPEG → Instagram konvertiert zu JPEG (Qualität ~85%)
|
||
→ **Generationsverlust** bei mehrfachem Re-Upload
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Instagram: Max. 1080×1080 Pixel, JPEG ~85% Qualität.
|
||
2. TikTok: Re-encodiert Video mit H.264, variable Bitrate.
|
||
3. Twitter: Aggressivere Kompression als Instagram.
|
||
|
||
## Tip für Nutzer
|
||
Für beste Qualität: Genau 1080×1080 hochladen (Instagram skaliert nicht). JPEG mit 90-95% Qualität exportieren (Instagram komprimiert auf ~85%, Puffer hilft).
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# VI. Video: Bilder + Zeit + Audio
|
||
|
||
---
|
||
|
||
# Das Größenproblem bei Video
|
||
|
||
**Recap: 1 Min 4K = ~45 GB unkomprimiert**
|
||
|
||
Ein 2-Stunden-Film: **5,4 Terabyte**
|
||
|
||
**Streaming unmöglich ohne Kompression:**
|
||
- Netflix 4K: ~15 Mbit/s (~7 GB/Stunde)
|
||
- YouTube 4K: ~20-40 Mbit/s (~10-20 GB/Stunde)
|
||
|
||
→ **Faktor 100-200× Kompression nötig!**
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Video ist Bilder + Zeit → Datenmenge multipliziert sich.
|
||
2. Ohne Kompression: kein Streaming, kein YouTube, kein Netflix.
|
||
3. Video-Codecs sind die komplexesten Kompressions-Algorithmen überhaupt.
|
||
-->
|
||
|
||
---
|
||
|
||
# Container und Codec
|
||
|
||
**Wichtige Unterscheidung:**
|
||
|
||
**Container (Wrapper):**
|
||
Datei-Format, das Video, Audio, Untertitel, Metadaten enthält
|
||
Beispiele: MP4, MKV, AVI, MOV, WebM
|
||
|
||
**Codec (Compressor/Decompressor):**
|
||
Algorithmus zur Kompression/Dekompression
|
||
Beispiele: H.264, H.265, VP9, AV1
|
||
|
||
**Container ≠ Codec!**
|
||
MP4 kann H.264, H.265, AV1, oder andere Codecs enthalten
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Analogie: Container = Schachtel, Codec = was drin ist.
|
||
2. .mp4 sagt nichts über Codec aus (könnte H.264 oder H.265 sein).
|
||
3. Tools wie MediaInfo zeigen Container + Codec.
|
||
|
||
## Beispiel
|
||
```
|
||
Datei: video.mp4
|
||
Container: MPEG-4
|
||
Video-Codec: H.264 (AVC)
|
||
Audio-Codec: AAC
|
||
```
|
||
-->
|
||
|
||
---
|
||
|
||
# Gängige Container
|
||
|
||
| Container | Endung | Codecs | Anwendung |
|
||
|-----------|--------|--------|-----------|
|
||
| **MP4** | .mp4, .m4v | H.264, H.265, AV1 | Web, Smartphones, universal |
|
||
| **MKV** | .mkv | Alle | Flexibel, Open-Source, Filme |
|
||
| **WebM** | .webm | VP8, VP9, AV1 | Web (HTML5), YouTube |
|
||
| **AVI** | .avi | Viele (alt) | Legacy (90er), veraltet |
|
||
| **MOV** | .mov | H.264, ProRes | Apple-Ökosystem, Editing |
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. MP4 = Standard (universellste Kompatibilität).
|
||
2. MKV = Flexibelster (alle Codecs, Features wie Kapitel, multiple Audio-Tracks).
|
||
3. WebM = Open-Source, von Google gepusht.
|
||
-->
|
||
|
||
---
|
||
|
||
# Video-Codecs
|
||
|
||
| Codec | Jahr | Effizienz | Status |
|
||
|-------|------|-----------|--------|
|
||
| **H.264 (AVC)** | 2003 | Basis | Standard, universell kompatibel |
|
||
| **H.265 (HEVC)** | 2013 | ~50% besser | Patente, teuer, langsame Adoption |
|
||
| **VP9** | 2013 | ~H.265 | Google, YouTube, patent-frei |
|
||
| **AV1** | 2018 | ~30% besser als H.265 | Zukunft, Netflix/YouTube, patent-frei |
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. H.264 dominiert noch (Kompatibilität, Hardware-Support).
|
||
2. H.265 technisch besser, aber Patentchaos bremste Adoption.
|
||
3. AV1 wird H.265 ablösen (patent-frei, AOMedia-Konsortium: Google, Netflix, Amazon, Apple).
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# VII. Video-Kompression im Detail
|
||
|
||
---
|
||
|
||
# Drei Kompressionsprinzipien
|
||
|
||
**1. Spatial Compression (Intra-Frame):**
|
||
Kompression **innerhalb** eines Frames (wie JPEG)
|
||
|
||
**2. Temporal Compression (Inter-Frame):**
|
||
Differenzen **zwischen** Frames (nur Änderungen speichern)
|
||
|
||
**3. Motion Compensation:**
|
||
Bewegungsvektoren statt volle Frames
|
||
|
||
→ **Kombination ermöglicht Faktor 100-200× Kompression**
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Intra-Frame: Jedes Frame einzeln komprimieren (ineffizient, aber notwendig für Schnitte).
|
||
2. Inter-Frame: Meiste Frames sind Differenzen (sehr effizient).
|
||
3. Motion Compensation: Statt "Block hat sich geändert" → "Block hat sich um 5 Pixel nach rechts bewegt".
|
||
-->
|
||
|
||
---
|
||
|
||
# 1. Spatial Compression (Intra-Frame)
|
||
|
||
**Prinzip:** Wie JPEG für Video-Frames
|
||
|
||
**I-Frames (Intra-coded):**
|
||
Vollständige Bilder, unabhängig von anderen Frames
|
||
→ Größer, aber notwendig für Schnitte, Wiedereinstiegspunkte
|
||
|
||
**Anwendung:**
|
||
Jedes N-te Frame ist I-Frame (z.B. alle 2 Sekunden)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
I-Frames = Schlüsselbilder (Keyframes). Beim Vorspulen/Schneiden muss Decoder zum nächsten I-Frame.
|
||
-->
|
||
|
||
---
|
||
|
||
# 2. Temporal Compression (Inter-Frame)
|
||
|
||
**Prinzip:** Speichere nur Änderungen zum vorherigen Frame
|
||
|
||
**P-Frames (Predicted):**
|
||
Referenzieren vorheriges Frame, speichern nur Differenzen
|
||
→ Viel kleiner als I-Frames
|
||
|
||
**B-Frames (Bi-directional):**
|
||
Referenzieren vorheriges **und** nächstes Frame
|
||
→ Noch kleiner, aber komplexer zu dekodieren
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Typische Sequenz: I B B P B B P B B I ...
|
||
2. P-Frames: ~10% der Größe von I-Frames.
|
||
3. B-Frames: ~5% der Größe von I-Frames.
|
||
|
||
## Beispiel
|
||
Interview-Video (Person spricht, Hintergrund statisch):
|
||
- I-Frame: 100 KB (voller Frame)
|
||
- P-Frame: 10 KB (nur Gesicht bewegt sich)
|
||
- B-Frame: 5 KB (kaum Änderung zwischen Frames)
|
||
-->
|
||
|
||
---
|
||
|
||
# 3. Motion Compensation
|
||
|
||
**Prinzip:** Bewegungsvektoren statt volle Blöcke
|
||
|
||
**Beispiel:**
|
||
Ball bewegt sich von (100,100) zu (150,100)
|
||
→ Statt neuen Ball speichern: "Kopiere Block von (100,100), verschiebe um (50,0)"
|
||
|
||
**Resultat:**
|
||
Bewegung wird mit wenigen Bytes kodiert statt komplettem Block
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Motion Vectors sind der Kern moderner Video-Codecs.
|
||
2. H.265/AV1 nutzen sehr ausgefeilte Motion Estimation (mehrere Referenz-Frames, adaptive Block-Größen).
|
||
3. Statische Szenen: Extrem effizient (fast keine Daten). Action-Szenen: Weniger effizient (viel Bewegung).
|
||
-->
|
||
|
||
---
|
||
|
||
# H.264 / AVC
|
||
|
||
**H.264 = MPEG-4 Part 10 / AVC (Advanced Video Coding)**
|
||
|
||
**Status:** De-facto Standard (seit 2003)
|
||
|
||
**Vorteile:**
|
||
- Universelle Hardware-Unterstützung (jedes Gerät kann dekodieren)
|
||
- Gute Qualität bei moderaten Bitraten
|
||
- Mature, stable
|
||
|
||
**Nachteile:**
|
||
- Patente (MPEG LA) → Lizenzgebühren
|
||
- Nicht so effizient wie H.265/AV1
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
H.264 wird noch Jahrzehnte bleiben (zu weit verbreitet, zu gut unterstützt).
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Patent-Problem
|
||
|
||
**H.264 Patente:**
|
||
MPEG LA Pool (viele Unternehmen)
|
||
Lizenzgebühren für Encoder/Decoder
|
||
→ Bremste Open-Source-Adoption
|
||
|
||
**H.265 noch schlimmer:**
|
||
Mehrere Patent-Pools, unklar wer zahlen muss
|
||
→ Viele Firmen verweigerten Adoption
|
||
|
||
**Reaktion:**
|
||
AOMedia (Google, Netflix, Amazon, Apple) → AV1 (patent-frei)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
Technologie ≠ Neutral. Patente beeinflussen, welche Standards sich durchsetzen.
|
||
-->
|
||
|
||
---
|
||
|
||
# VP9: Googles Antwort
|
||
|
||
**VP9 (2013):** Googles patent-freie Alternative zu H.265
|
||
|
||
**Status:**
|
||
- YouTube Standard (>90% der Videos)
|
||
- Android, Chrome unterstützen
|
||
- Ähnliche Effizienz wie H.265
|
||
|
||
**Problem:**
|
||
Wenig Hardware-Support (Software-Dekodierung → Batterie)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
VP9 war Übergangslösung. AV1 ist Nachfolger (noch besser, patent-frei).
|
||
-->
|
||
|
||
---
|
||
|
||
# AV1: Die offene Zukunft
|
||
|
||
**AV1 (2018):** AOMedia Video Codec 1
|
||
|
||
**Vorteile:**
|
||
- ~30% effizienter als H.265
|
||
- Patent-frei (Royalty-free)
|
||
- Netflix, YouTube nutzen es
|
||
|
||
**Nachteile:**
|
||
- Langsam zu encodieren (CPU-intensiv)
|
||
- Hardware-Support wächst erst jetzt
|
||
|
||
**Ausblick:**
|
||
Wird H.265 langfristig ersetzen
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. AOMedia = Konsortium (Google, Netflix, Amazon, Apple, Microsoft, Intel, ARM).
|
||
2. AV1 designed für Streaming (adaptive bitrate, error resilience).
|
||
3. Hardware-Decoder in neuen GPUs (NVIDIA RTX 30xx+, Intel Arc, Apple M3).
|
||
|
||
## Beispiel
|
||
YouTube: Bietet AV1 für 4K/8K wenn Browser/Device unterstützt, sonst VP9 oder H.264 Fallback.
|
||
-->
|
||
|
||
---
|
||
|
||
# Adaptive Bitrate Streaming
|
||
|
||
**Problem:** Nutzer haben verschiedene Bandbreiten
|
||
|
||
**Lösung:** Video in mehreren Qualitätsstufen encodieren
|
||
|
||
**Beispiel:**
|
||
- 360p @ 1 Mbit/s
|
||
- 720p @ 3 Mbit/s
|
||
- 1080p @ 6 Mbit/s
|
||
- 4K @ 15 Mbit/s
|
||
|
||
**Client wählt dynamisch** je nach Bandbreite
|
||
|
||
**Technologien:**
|
||
MPEG-DASH (Standard), HLS (Apple)
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Streaming-Dienste encodieren jedes Video mehrfach (ineffizient für Server, optimal für Nutzer).
|
||
2. Client misst Bandbreite kontinuierlich, switcht Qualität nahtlos.
|
||
3. Warum YouTube manchmal "buffert": Client wechselt zu niedrigerer Qualität.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# VIII. Kritische Perspektive: Deepfakes & Manipulation
|
||
|
||
---
|
||
|
||
# Wenn Codecs lügen
|
||
|
||
**Deepfakes nutzen Codec-Schwächen:**
|
||
|
||
Moderne ML-Modelle (GANs) erzeugen synthetische Videos
|
||
→ Müssen nur "gut genug für H.264" sein, nicht pixel-perfekt
|
||
|
||
**Compression Artifacts als Forensik:**
|
||
|
||
Echte Kamera-Footage hat charakteristische Muster
|
||
Synthetische Videos zeigen andere Artefakte
|
||
→ Forensische Tools nutzen das zur Erkennung
|
||
|
||
**Ethische Dimension:**
|
||
|
||
Als Medienschaffende: Verantwortung, nicht zu täuschen
|
||
Technisches Wissen befähigt, Manipulationen zu erkennen
|
||
|
||
<!--
|
||
## Kernaussagen
|
||
1. Codecs optimieren für menschliche Wahrnehmung → Angreifbar für ML-generierte Fakes.
|
||
2. Paradox: Artefakte helfen bei Verifikation (Echtheitsprüfung).
|
||
3. Deepfake-Detektion: Aktive Forschung (Analyse von Kompressionsmustern, Frequenz-Anomalien, Augen-Blick-Muster).
|
||
|
||
## Beispiel
|
||
2019: Deepfake-Video von Mark Zuckerberg. Forensische Analyse zeigte unnatürliche Kompressionsartefakte um Gesicht.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# IX. Abschluss
|
||
|
||
---
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Was wir heute gelernt haben:**
|
||
|
||
1. **Digitale Bilder:** Raster vs. Vektor, Skalierungsprobleme
|
||
2. **Psychovisuell:** Chroma Subsampling, Schwächen des Auges
|
||
3. **JPEG:** 6-Schritte-Kompression, Artefakte
|
||
4. **Formate:** PNG, GIF, WebP, AVIF
|
||
5. **Instagram-Problem:** Re-Kompression, Generationsverlust
|
||
6. **Video:** Container vs. Codec, Spatial/Temporal Compression
|
||
7. **Codecs:** H.264, H.265, VP9, AV1, Patent-Probleme
|
||
8. **Deepfakes:** Ethische Verantwortung
|
||
|
||
**Fragen?**
|
||
|
||
---
|
||
|
||
# Selbstlernen: Bildkompression experimentieren
|
||
|
||
**Aufgabe:** Exportiert ein Foto in verschiedenen JPEG-Qualitätsstufen
|
||
|
||
**Tools:**
|
||
- GIMP (kostenlos, Open-Source)
|
||
- Photopea (Browser-basiert, kostenlos)
|
||
|
||
**Experiment:**
|
||
1. Exportiere mit Qualität 100, 85, 70, 50, 10
|
||
2. Vergleiche Dateigröße und visuelle Qualität
|
||
3. Wo werden Artefakte sichtbar?
|
||
|
||
**Link:** [https://www.photopea.com/](https://www.photopea.com/)
|
||
|
||
---
|
||
|
||
# Selbstlernen: Video analysieren
|
||
|
||
**Aufgabe:** Analysiert eine Video-Datei mit MediaInfo
|
||
|
||
**Tool:** MediaInfo (kostenlos)
|
||
[https://mediaarea.net/en/MediaInfo](https://mediaarea.net/en/MediaInfo)
|
||
|
||
**Fragen:**
|
||
- Welcher Container?
|
||
- Welcher Video-Codec?
|
||
- Welche Bitrate?
|
||
- I-Frame-Abstand?
|
||
|
||
**Bonus:** Vergleicht YouTube-Video (Download mit yt-dlp) vs. eigene Aufnahme
|
||
|
||
---
|
||
|
||
# Lizenz & Attribution
|
||
|
||
**Dieses Foliendeck:**
|
||
© 2025 Michael Czechowski
|
||
Lizenz: CC BY-SA 4.0
|
||
|
||
**Quellen:**
|
||
- Wallace, G. K. (1992). "The JPEG Still Picture Compression Standard." *IEEE Transactions on Consumer Electronics*.
|
||
- Sullivan, G. J., et al. (2012). "Overview of the High Efficiency Video Coding (HEVC) Standard." *IEEE Transactions on Circuits and Systems for Video Technology*.
|
||
- AOMedia (2018). AV1 Bitstream & Decoding Process Specification.
|
||
|
||
**Kontakt:** [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|