Michael Czechowski
ccceac83e4
- change huffman coding example from numbers to vowels (a,e,i,o,u) - add !important to klausur gradient for pdf printing
1120 lines
25 KiB
Markdown
1120 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
|
||
---
|
||
|
||
<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;
|
||
}
|
||
section.aufgabe {
|
||
background: #e3f2fd !important;
|
||
}
|
||
section.aufgabe footer {
|
||
display: none;
|
||
}
|
||
</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/)
|
||
|
||
---
|
||
|
||
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Links: Hochauflösend
|
||
Rechts: Stark komprimiert (JPEG-Artefakte sichtbar)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Digitale Bilder
|
||
## Raster- und Vektorgrafiken
|
||
|
||
---
|
||
|
||
# Was ist ein digitales Bild?
|
||
|
||
**Rasterbild = Pixelraster**
|
||
|
||
**Beispiel: Full HD (1920×1080)**
|
||
= 2.073.600 Pixel
|
||
|
||
**Jedes Pixel = 3 Bytes (RGB)**
|
||
2.073.600 × 3 = **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)
|
||
|
||
**Farbtiefe:**
|
||
| Bits | 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** | 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 -->
|
||
|
||
# JPEG
|
||
## Psychovisuell komprimieren
|
||
|
||
---
|
||
|
||
# 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
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG: Schritt 1 – Farbraum
|
||
|
||
**RGB → YCbCr** (auch 3 Werte pro Pixel, nur anders aufgeteilt)
|
||
|
||
- **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.
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
# 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 Unterschied.
|
||
|
||
<!--
|
||
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.
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
**Der Quality-Schieberegler steuert das:**
|
||
- Quality 100: Minimale Quantisierung
|
||
- Quality 50: Aggressive Quantisierung
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Beispiel: Stark komprimiertes JPEG
|
||
Blocking (8×8-Blöcke sichtbar)
|
||
Ringing (Geister um Kanten)
|
||
Color Banding (Verläufe werden "treppig")
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG-Artefakte
|
||
|
||
**Bei hoher Kompression sichtbar:**
|
||
|
||
**Blocking:**
|
||
8×8-Blöcke werden sichtbar (Block-Grenzen)
|
||
|
||
**Ringing:**
|
||
"Geister" um scharfe Kanten (Gibbs-Phänomen)
|
||
|
||
**Color Banding:**
|
||
Farbverläufe werden stufig
|
||
|
||
<!--
|
||
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.
|
||
|
||
<!--
|
||
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 -->
|
||
|
||
# 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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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
|
||
|
||
<!--
|
||
Spatial: Innerhalb eines Bildes (räumlich)
|
||
Temporal: Zwischen Bildern (zeitlich)
|
||
|
||
Video hat massive zeitliche Redundanz.
|
||
90% eines Frames ist oft identisch mit dem vorherigen.
|
||
-->
|
||
|
||
---
|
||
|
||
# I-Frames, P-Frames, B-Frames
|
||
|
||
**I-Frame (Intra):**
|
||
Vollständiges Bild, unabhängig komprimiert
|
||
Groß, aber Ankerpunkt für Navigation
|
||
|
||
**P-Frame (Predicted):**
|
||
Referenziert vorherige Frames
|
||
Speichert nur Unterschiede
|
||
|
||
**B-Frame (Bi-directional):**
|
||
Referenziert vorherige UND zukünftige Frames
|
||
Beste Kompression, aber komplexer
|
||
|
||
<!--
|
||
GOP = Group of Pictures
|
||
Typisch: I - B - B - P - B - B - P - B - B - I
|
||
|
||
I-Frames alle 1-2 Sekunden für Seeking.
|
||
Wenn du im Video springst, sucht der Player den nächsten I-Frame.
|
||
|
||
B-Frames sind am effizientesten, aber erfordern Lookahead.
|
||
-->
|
||
|
||
---
|
||
|
||
# Motion Compensation
|
||
|
||
**Idee:** Bewegung beschreiben statt Pixel kopieren.
|
||
|
||
**Beispiel:**
|
||
Frame 1: Ball bei Position (100, 200)
|
||
Frame 2: Ball bei Position (120, 200)
|
||
|
||
**Statt 2 komplette Frames:**
|
||
"Ball bewegt sich 20 Pixel nach rechts"
|
||
|
||
**Enormer Effizienzgewinn bei Video mit Bewegung.**
|
||
|
||
<!--
|
||
Motion Vectors beschreiben Bewegung von Blöcken.
|
||
Der Decoder rekonstruiert das Bild aus Referenz + Bewegung.
|
||
|
||
Funktioniert gut bei: Kameraschwenks, bewegten Objekten.
|
||
Funktioniert schlecht bei: Szenenwechseln, Chaos (Konfetti).
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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.
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!-- _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/' -->
|
||
|
||
|
||
|
||
|
||
<!--
|
||
|
||
---
|
||
|
||
# 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: '' -->
|
||
|
||
|
||
|
||
# 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.
|
||
-->
|