---
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;
}
@media print {
  section.klausur {
    background: #e3f2fd !important;
  }
}
</style>

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

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

# Dateiformate, Schnittstellen, Speichermedien & Distributionswege

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

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

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

---

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

---

<!-- _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�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/)