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

<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #1e5f8a;
  --color-dimmed: #4a4a6a;
}
section.invert {
  --color-foreground: #fff;
}
section {
  font-size: 1.7rem;
}
h1 {
  color: #1e5f8a;
}
section.invert h1 {
  color: #fff;
}
h2 {
  color: #1f2937;
}
pre {
  background: #0f0f23;
  color: #5fb3e4;
  border-radius: 8px;
  border-left: 3px solid #1e5f8a;
}
pre code {
  background: transparent;
  color: inherit;
}
code {
  background: #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;
  }
}
section.aufgabe {
  background: #e3f2fd !important;
}
section.aufgabe footer {
  display: none;
}
</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/)

---



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

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

---

<!-- _class: lead -->

# Teil 2: Bild- & Videoformate

---

# Warum verschiedene Dateiformate?

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

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

<!--
Dateiformate sind Kompromisse zwischen Größe, Qualität und Features.
Die Wahl hängt vom Anwendungsfall ab.
-->

---

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

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

<!--
Links: Hochauflösend
Rechts: Stark komprimiert (JPEG-Artefakte sichtbar)
-->

---

<!-- _class: lead -->

# Digitale Bilder
## Raster- und Vektorgrafiken

---

# Was ist ein digitales Bild?

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

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

<!--
Zoom auf Pixel-Ebene zeigen.
Jedes Pixel = RGB-Tripel (3 Bytes für 24-Bit-Farbe)
6 MB × 10.000 Fotos = 62 GB
Smartphone-Speicher wäre ohne Kompression sofort voll.
-->

---

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

# Rastergrafiken

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

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

**Beispiele:** JPEG, PNG, WebP

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

<!--
BERECHNUNG: Breite × Höhe × (Farbtiefe / 8)
BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB

Farbtiefe erklärt:
- 1 Bit: 2^1 = 2 Farben
- 8 Bit: 2^8 = 256 Farben
- 24 Bit: 2^24 = 16.777.216 Farben (je 8 Bit für R, G, B)
- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal
-->

---

# Das Problem der Skalierung

**Vergrößern:**
Fehlende Pixel müssen erfunden werden (Interpolation)

**Verkleinern:**
Pixel müssen zusammengefasst werden

**Interpolationsverfahren:**
- Nearest Neighbor: Schnell, pixelig
- Bilinear: Standard, glättet
- Bicubic: Hohe Qualität, rechenintensiv
- Lanczos: Beste Qualität

<!--
Nearest Neighbor: Gut für Pixel-Art (soll pixelig bleiben)
Bilinear: Mittelwert aus 4 Nachbarn
Bicubic: 16 Nachbarn, Photoshop-Standard
Lanczos: Mathematisch aufwendig, beste Ergebnisse

Das fundamentale Problem: Rasterbilder haben eine native Auflösung.
Alles darüber ist Schätzung.
-->

---

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

# Vektorgrafiken

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

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

<small>SVG beschreibt nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden.</small>

<!--
Vektorgrafiken beschreiben WAS gezeichnet werden soll.
Rastergrafiken beschreiben WIE jeder Pixel aussieht.

Rendering-Pipeline:
Vektordaten → Rasterisierung → Framebuffer → Display

Beim Skalieren werden einfach die Koordinaten multipliziert.
Keine Information geht verloren.
-->

---

# Raster- und Vektorgrafiken

| | Raster | Vektor |
|---|---|---|
| **Optimal für** | Fotos, komplexe Bilder | Logos, Icons, Illustrationen |
| **Skalierung** | Qualitätsverlust | Verlustfrei |
| **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität |
| **Formate** | JPEG, PNG, WebP | SVG, PDF, AI |
| **Bearbeitung** | Pixel-basiert | Objekt-basiert |
| **Kompression** | meistens verlustbehaftet | Verlustfrei |

<!--
Die Entscheidung hängt vom Inhalt ab:
- Foto: Immer Raster (Millionen unterschiedlicher Pixel)
- Logo: Immer Vektor (wenige geometrische Formen)
- Screenshot: Meist Raster, aber für UI-Elemente manchmal Vektor

Konvertierung:
- Vektor → Raster: Trivial (Rasterisierung)
- Raster → Vektor: Komplex, oft unbefriedigend (Tracing)
-->

---

<!-- _class: lead -->

# Menschliche Sinne
## Psychovisuell komprimieren

---

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

# Die Schwächen des Auges

**Menschen sehen:**
* Helligkeit besser als Farbe
* Große Flächen besser als feine Details
* Niedrige Frequenzen besser als hohe

**JPEG nutzt das aus:**
* Farbauflösung reduzieren (aber Helligkeit behalten)
* Glatte Flächen effizient speichern
* Hohe Frequenzen (Details) verwerfen

<!--
Das ist die visuelle Entsprechung zur Psychoakustik.

Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen)
als für Farbe (Zapfen).

Hohe Frequenzen = schnelle Wechsel = feine Details
Niedrige Frequenzen = langsame Wechsel = große Flächen
-->

---

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

<!--![bg contain 50%](./assets/Asterisk_with_jpg-artefacts.png)-->
![bg contain 50%](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg)

---

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

# Grenzen der Kompression: JPEG-Artefakte

**Bei hoher Kompression sichtbar:**

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

* **"Blocking":**
  8×8-Blöcke werden sichtbar (Block-Grenzen)

* **Ringing:**
  "Ghosting" an scharfen Kanten (Gibbs’sches Phänomen)

<!--
Diese Artefakte entstehen durch die 8×8-Block-Struktur
und aggressive Quantisierung.

Blocking: Benachbarte Blöcke werden unabhängig komprimiert.
Ringing: DCT hat Probleme mit harten Kanten.
Banding: Zu wenig Bits für feine Farbabstufungen.
-->

---

# JPEG-Qualität in der Praxis

| Quality¹ | Typische Größe (12 MP) | Artefakte |
|--------:|----------------------:|-----------|
| 100 | 2-3 MB | Minimal |
| 85-90 | 200-400 KB | Kaum sichtbar |
| 60 | ~100 KB | Bei genauem Hinsehen |
| 30 | ~50 KB | Deutlich sichtbar |

**Sweet Spot: 85-90**
~10× Kompression, für Menschen kaum unterscheidbar.

<small>¹ je nach Programm seine eigene Bedeutung von bspw. f80%</small>

<!--
Quality 100 ist nicht "unkomprimiert".
Es ist minimale Lossy-Kompression.

Für Web und Social Media: 60-80 oft ausreichend.
Für Archivierung: 90-100 oder gleich PNG/RAW.
-->



---

<!-- _class: lead -->

# JPEG
## Vier Schritte der Kompression

---

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

# JPEG: Schritt 1 – Farbraum wechseln

**RGB → Y'CbCr** (seltener Y'UV)

- **Y** = Helligkeit (Luminanz) – Was das Auge am besten sieht
- **Cb** = Blau-Gelb-Anteil (Chrominanz)
- **Cr** = Rot-Grün-Anteil (Chrominanz)

**Warum diese Trennung?**
Y (Helligkeit) behält volle Auflösung.
Cb/Cr (Farbe) kann reduziert werden – Auge merkt es kaum.

<!--
YCbCr ist wie RGB ein Tripel aus 3 Werten pro Pixel.
Der Unterschied: Statt Rot-Grün-Blau speichern wir Helligkeit + 2 Farbdifferenzen.

Die Umrechnung ist reversibel (mathematische Transformation).
Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
-->

---

# JPEG: Schritt 2 – Chroma Subsampling

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

| Schema | Bedeutung | Farbdaten |
|--------|-----------|-----------|
| 4:4:4 | Jedes Pixel hat Farbinfo | 100% |
| 4:2:2 | Jedes 2. Pixel horizontal | 50% |
| 4:2:0 | Jedes 4. Pixel (2×2 Block teilt sich Farbe) | 25% |

**4:2:0 ist JPEG-Standard** – kaum sichtbarer Qualitätsverlust

<!--
Beispiel 4:2:0: In einem 2×2-Block haben alle 4 Pixel denselben Cb/Cr-Wert,
aber jedes Pixel behält seinen eigenen Y-Wert (Helligkeit).
Das Auge merkt es kaum, weil Helligkeit erhalten bleibt.
-->

---

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

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

---

# JPEG: Schritt 3 – DCT

**Discrete Cosine Transform:**
Bild in 8×8-Pixel-Blöcke aufteilen.
Jeden Block in **räumliche Frequenzen** zerlegen.

**Räumliche Frequenz = Wie schnell ändern sich Pixelwerte?**
- **Niedrig:** Große, gleichmäßige Flächen (Himmel)
- **Hoch:** Schnelle Wechsel, feine Details (Haare, Kanten)

<!--

**Vorteil:** Die meiste Bildinformation steckt in niedrigen Frequenzen.

NICHT Tonhöhe! Räumliche Frequenz = Änderungsrate der Helligkeit im Raum.

Niedrige Frequenz: Langsamer Übergang von hell zu dunkel
Hohe Frequenz: Schneller Wechsel (z.B. Schachbrettmuster)

DCT ist wie ein Prisma: Zerlegt das Bild in seine Frequenzkomponenten.
-->

---

# JPEG: Schritt 4 – Quantisierung

**Hier passiert der Datenverlust.**

Hohe räumliche Frequenzen (Details) → grob speichern oder weglassen
Niedrige Frequenzen (Flächen) → erhalten


<!--
Quantisierung = Division durch Quantisierungsmatrix + Rundung.
Je höher die Zahl in der Matrix, desto mehr wird verworfen.

Quality 100 ist nicht verlustfrei! Es ist nur minimaler Verlust.
-->

---

# JPEG: Schritt 5 – Zigzag & RLE

**Nach Quantisierung:** Viele Werte sind 0 (v.a. hohe Frequenzen).

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

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

**RLE:** `0 0 0 0 0 0 0 0` → `(8, 0)` = "8 Nullen"

<!--
Zigzag sortiert so, dass Nullen am Ende stehen.
Lange Null-Sequenzen sind ideal für RLE.
-->

---

# JPEG: Schritt 6 – Huffman-Coding

**Verlustfreie Kompression der Restwerte**

**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge
Häufige Werte bekommen kurze Bit-Sequenzen.

| Zeichen | Häufigkeit | Code (Bit-Sequenz) |
|---------|------------|------|
| e | 40% | `0` (1 Bit) |
| a | 25% | `10` (2 Bit) |
| i | 20% | `110` (3 Bit) |
| o | 10% | `1110` (4 Bit) |
| u | 5% | `1111` (4 Bit) |

<!--
Huffman-Coding ist verlustfrei.
Der "Code" ist eine Bit-Sequenz, die das Zeichen eindeutig identifiziert.
Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
-->

---

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

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

<!--
Beispiel: Stark komprimiertes JPEG
Blocking (8×8-Blöcke sichtbar)
Ringing (Geister um Kanten)
Color Banding (Verläufe werden "treppig")
-->

---

<!-- _class: lead -->

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

---

# PNG: Verlustfrei mit Transparenz

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

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

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

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

<!--
PNG entstand als Reaktion auf die GIF-Lizenzprobleme.
"PNG is Not GIF" war ein früher Slogan.

DEFLATE-Kompression (wie ZIP).
Keine Qualitätsverluste, aber größer als JPEG für Fotos.
-->

---

# GIF: Der Meme-Veteran

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

**Features:**
- 256 Farben (8-Bit Palette)
- Verlustfrei (für die gewählte Palette)
- Animationen

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

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

<!--
CompuServe entwickelte GIF 1987.
LZW = Lempel-Ziv-Welch Kompression.

Patent lief 2004 aus, aber da war PNG längst etabliert.
GIF überlebte wegen Animationen und Netzwerkeffekten.

Die Aussprache "GIF" vs. "JIF" bleibt ewiger Streit.
Der Erfinder sagt "JIF", das Internet sagt "GIF".
-->

---

# WebP & AVIF: Moderne Alternativen

**WebP (Google, 2010):**
- Lossy und Lossless
- Transparenz und Animationen
- 25-35% kleiner als JPEG

**AVIF (2019):**
- Basiert auf AV1-Video-Codec
- 50% kleiner als JPEG, HDR, patent-frei

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

<!--
WebP nutzt VP8-Kompression (Googles Video-Codec).
Skepsis wegen Google-Dominanz, aber technisch überlegen.

AVIF kommt von der Alliance for Open Media.
Noch besser als WebP, aber Encoding ist langsam.

JPEG bleibt dominant wegen Kompatibilität.
Alte Kameras, alte Software, alte Workflows.
-->

---

# Formatwahl in der Praxis

| Anwendung | Format |
|-----------|--------|
| Fotos fürs Web | JPEG (85), WebP |
| Screenshots | PNG |
| Logos, Icons | SVG, PNG |
| Animationen | GIF, WebP, APNG |
| Archivierung | TIFF, PNG, RAW |
| Social Media | Was die Plattform erlaubt |

<!--
Die Wahl hängt vom Kontext ab.
Kompatibilität schlägt oft Effizienz.

TIFF für Archivierung: Unkomprimiert oder verlustfrei.
RAW für Fotografen: Maximale Bearbeitungsmöglichkeit.
-->

---

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

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

<!--
Vorher/Nachher: Original vs. Instagram-Upload
Sichtbare Qualitätsverluste
-->

---

# Warum Instagram eure Fotos "ruiniert"

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

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

<!--
Instagram ist keine Kunstgalerie.
Optimiert für Geschwindigkeit und Skalierung.

Facebook, Twitter, alle machen das.
Manche besser, manche schlechter.

Für Fotografen: Portfolio auf eigener Website,
nicht auf Social Media verlassen.
-->

---

<!-- _class: lead -->

# Video
## Bilder + Zeit + Audio

---

# Das Größenproblem bei Video

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

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

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

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

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

<!--
Das ist der Grund, warum Video-Kompression existiert.
Ohne sie wäre Streaming unmöglich.
Blu-rays könnten nicht existieren.
Netflix wäre undenkbar.
-->

---

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

# Container und Codec

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

**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)**
Entscheidet, WIE komprimiert wird.


<!--
Container ≠ Codec
Das ist ein häufiges Missverständnis.

MP4 ist ein Container, nicht ein Codec.
Ein MP4 kann H.264, H.265 oder AV1 enthalten.

Übrigens: JPEG ist ein Codec (für Bilder), kein Container.
Bei Bildern fallen Container und Codec oft zusammen.

Tools wie MediaInfo zeigen beide Informationen.
-->

---

# Gängige Container

| Container | Verwendung |
|-----------|------------|
| **MP4** (.mp4) | Web, Streaming, universell |
| **MKV** (.mkv) | Archiv, viele Streams, offen |
| **MOV** (.mov) | Apple-Ökosystem |
| **WebM** (.webm) | Web, nur VP9/AV1 + Opus |
| **AVI** (.avi) | Legacy, veraltet |

<!--
MP4 = MPEG-4 Part 14, ISO-Standard.
MKV = Matroska (russisch: Matrjoschka-Puppen).
WebM = Subset von Matroska für HTML5.

MKV kann beliebig viele Audio- und Untertitelspuren haben.
Beliebt für Filme mit mehreren Sprachen.
-->

---

# Video-Codecs

| Codec | Jahr | Status |
|-------|------|--------|
| **MPEG-4** | 1999 | Passender Codec zu .mp4 |
| **H.264/AVC** | 2003 | Universal, überall |
| **H.265/HEVC** | 2013 | Effizienter, aber Patente |
| **VP9** | 2013 | YouTube, patent-frei |
| **AV1** | 2018 | Zukunft, patent-frei |

<!--
H.264 ist der De-facto-Standard seit 20 Jahren.
Hardware-Decoder in jedem Gerät seit ~2010.

H.265 ist 50% effizienter, aber Patent-Chaos.
Drei konkurrierende Patent-Pools.

AV1 ist die Antwort: Offen, modern, aber Encoding ist langsam.
-->

---

# Container + Codec = Video

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

<!--
Der Container ist die Verpackung.
Der Codec bestimmt, wie der Inhalt komprimiert ist.

Ein MP4 mit H.264 und ein MP4 mit H.265
haben dieselbe Endung, aber unterschiedliche Inhalte.
-->

---

<!-- _class: lead -->

# Video-Kompression
## Raum und Zeit nutzen


---

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

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

<!--
Visualisierung: I/P/B-Frame-Abhängigkeiten
I-Frame = Vollbild (Keyframe)
P/B-Frames speichern nur Unterschiede
-->

---

# Drei Kompressionsprinzipien

* **1. Spatial Compression (Intra-Frame)**
  Jedes Bild einzeln komprimieren (wie JPEG)

* **2. Temporal Compression (Inter-Frame)**
  Nur Änderungen zwischen Bildern speichern

* **3. Motion Compensation**
  Bewegung beschreiben statt Pixel kopieren

<!--
BEGRIFFE:
- Spatial = Intra-Frame: Kompression innerhalb eines Bildes (2D, wie JPEG)
- Temporal = Inter-Frame: Kompression zwischen Bildern (über Zeit)
- Motion Compensation: Technik innerhalb von Inter-Frame

ZUSAMMENHANG:
- I-Frames nutzen nur Intra-Frame/Spatial (jedes Bild für sich)
- P/B-Frames nutzen Inter-Frame/Temporal + Motion Compensation

Video hat massive zeitliche Redundanz.
90% eines Frames ist oft identisch mit dem vorherigen.

QUELLEN:
- O'Reilly "Web Design in a Nutshell" Ch. 34.2.2: https://www.oreilly.com/library/view/web-design-in/0596009879/ch34s02s02.html
- ScienceDirect "Temporal Compression": https://www.sciencedirect.com/topics/computer-science/temporal-compression
-->

---

# 1. Spatial Compression (Intra-Frame)

**Jedes Bild einzeln komprimieren – wie JPEG**

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

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

<!--
I = Intra = innerhalb
Wenn du im Video springst, sucht der Player den nächsten I-Frame.
-->

---

# 2. Temporal Compression (Inter-Frame)

**Nur Änderungen zwischen Bildern speichern**

| Frame-Typ | Referenziert | Größe |
|-----------|--------------|-------|
| **I-Frame** (Intra) | Keine Referenz (Keyframe) | 100% |
| **P-Frame** (Predicted) | Vorherige Frames | ~30% |
| **B-Frame** (Bi-directional) | Vorherige + zukünftige | ~15% |

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

<!--
ABKÜRZUNGEN:
- I = Intra (innerhalb) – vollständiges Bild
- P = Predicted (vorhergesagt) – basiert auf vorherigen
- B = Bi-directional (bidirektional) – vorherige + zukünftige

90% eines Frames ist oft identisch mit dem vorherigen.
P/B-Frames sind winzig im Vergleich zu I-Frames.
I-Frames alle 1-2 Sekunden für Seeking.
-->

---

# 3. Motion Compensation

**Bewegung beschreiben statt Pixel kopieren**

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

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

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

<!--
Macroblocks: Typisch 16×16 oder 8×8 Pixel.
Motion Vectors beschreiben Verschiebung jedes Blocks.
Funktioniert gut bei: Kameraschwenks, bewegte Objekte.
Funktioniert schlecht bei: Szenenwechsel, Konfetti.
-->


---

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

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

<!--
Visualisierung: I/P/B-Frame-Abhängigkeiten
I-Frame = Vollbild (Keyframe)
P/B-Frames speichern nur Unterschiede
-->

---

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

# H.264 / AVC

**Advanced Video Coding (2003)**

**Warum dominant?**
- Exzellente Kompression (~100:1 möglich)
- Hardware-Support in jedem Gerät seit ~2010
- YouTube, Netflix, Blu-ray – alles H.264

**Features:**
- Variable Block-Größen (16×16 bis 4×4)
- Deblocking-Filter (reduziert Block-Artefakte)

<!--
H.264 revolutionierte Video-Streaming.
Ohne H.264 kein Netflix, kein YouTube in HD.

Hardware-Decoder bedeutet: Kein CPU-Aufwand, kein Akku-Drain.
Selbst billige Smartphones können H.264 abspielen.
-->

---

# Das Patent-Problem

**H.264 ist nicht frei.**

**MPEG-LA (Patent Pool):**
- 2.000+ Patente von ~30 Unternehmen
- Apple, Microsoft, Sony, Panasonic...

**Lizenzgebühren:**
- Hardware-Decoder: $0,20 pro Einheit
- "Internet Broadcast": Kostenlos (YouTube etc.)

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

<!--
MPEG-LA = Licensing Authority
Patent-Pool: Firmen teilen Patente, gemeinsame Lizenzierung.

Firefox weigerte sich lange, H.264 zu unterstützen.
Chromium musste extern linken.

Die "Free to View"-Klausel gilt nur für Endnutzer-Streaming.
-->

---

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

**High Efficiency Video Coding (2013)**

50% bessere Kompression als H.264.

**Das Problem: Patent-Chaos**

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

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

<!--
Technisch ist H.265 überlegen.
4K-Streaming wäre ohne H.265/VP9/AV1 nicht praktikabel.

Aber die fragmentierte Lizenzsituation verhinderte Adoption.
Apple nutzt HEVC (iPhone-Videos), Netflix zögert.
-->

---

# VP9: Googles Antwort

**VP9 (2013)**

Google kaufte On2 Technologies (2010, $133M).
VP8 → VP9 → (später) AV1

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

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

<!--
YouTube forciert VP9: 4K-Videos nur in VP9 oder AV1.
Das treibt die Adoption.

Hardware-Decoder ab ~2016 in GPUs.
Heute in allen modernen Geräten.
-->

---

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

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

# AV1: Die offene Zukunft

**AV1 (2018)**

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

**Eigenschaften:**
- 30% besser als H.265
- Royalty-free, Open Source
- 8K, HDR, hohe Frame-Rates

**Stand 2025:**
YouTube und Netflix nutzen AV1 für 4K/8K
Hardware-Encoder in aktuellen GPUs

<!--
AOM = Alliance for Open Media, gegründet 2015.
Historisch: Konkurrierende Tech-Giganten vereint.

Das Ziel: Nie wieder Patent-Chaos wie bei H.265.

Problem: Encoding ist sehr langsam (10-100× vs. H.264).
Hardware-Encoder lösen das zunehmend.
-->

---


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

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


<!--

---

# Adaptive Bitrate Streaming

**Problem:** Internet-Geschwindigkeit variiert

**Lösung:** Mehrere Qualitätsstufen parallel

**MPEG-DASH / HLS:**
- 4K: 20 Mbps
- 1080p: 5 Mbps
- 720p: 2,5 Mbps
- 480p: 1 Mbps

Player wählt dynamisch basierend auf Bandbreite.

DASH = Dynamic Adaptive Streaming over HTTP
HLS = HTTP Live Streaming (Apple)

Video in 2-10 Sekunden-Segmente aufgeteilt.
Manifest-Datei listet alle verfügbaren Qualitäten.

Deshalb wird Netflix manchmal plötzlich pixelig:
Bandbreite sinkt → Player wechselt auf niedrigere Qualität.
-->

---

<!-- _class: lead -->

# Fragen & Diskussion

**Kontakt:** mail@librete.ch
**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)

---

# Lizenz & Attribution

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

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

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

---


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

![bg contain right:25%](./assets/qr/squoosh.png)

# Selbstlernen: Bildkompression

1. Öffne [squoosh.app](https://squoosh.app)
2. Lade ein Foto hoch
3. Vergleiche: JPEG (verschiedene Quality) vs. WebP vs. AVIF
4. Beobachte: Dateigröße, Artefakte, Ladezeit

**Fragen:**
- Ab welcher Quality werden Artefakte sichtbar?
- Wie viel kleiner ist WebP bei gleicher Qualität?

<!--
Squoosh ist ein Google-Tool zum Vergleichen von Bildformaten.
Zeigt Live-Vergleich mit Schieberegler.

Ziel: Ein Gefühl für Kompressionsraten entwickeln.
-->

---

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

# Selbstlernen: Video analysieren

1. Video herunterladen (z.B. Big Buck Bunny)
2. Mit MediaInfo analysieren: Container, Codec, Bitrate
3. Optional: Mit HandBrake konvertieren
   - H.264 vs. H.265 bei gleicher Qualität
   - Größe und Encoding-Zeit vergleichen

**Tools:**
- [MediaInfo](https://mediaarea.net/MediaInfoOnline) (Online oder Desktop)
- [HandBrake](https://handbrake.fr) (Desktop)

<!--
Big Buck Bunny: Open-Source-Film der Blender Foundation.
Frei verfügbar, ideal zum Experimentieren.

FFmpeg ist das mächtigste Tool, aber komplex.
HandBrake bietet eine GUI für FFmpeg.
-->