Michael Czechowski
278509577d
223015b: - add klausur styles to termin-3, 4, 5 - consistent styles across all 6 termine 223015c: - h1: darker raspberry (#a02060) - h2: dark gray almost black (#1f2937) - section.invert h1: white - consistent styles across all 3 termine also: - add squoosh link and QR code - update video title to "RIIIIIIIESIG" - replace i-frame diagram with canon image
881 lines
19 KiB
Markdown
881 lines
19 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
|
||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #5da9e9;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert {
|
||
--color-foreground: #fff;
|
||
}
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h2 {
|
||
color: var(--color-highlight);
|
||
}
|
||
pre {
|
||
background: #0f0f23;
|
||
color: #5da9e9;
|
||
border-radius: 8px;
|
||
border-left: 3px solid #5da9e9;
|
||
}
|
||
pre code {
|
||
background: transparent;
|
||
color: inherit;
|
||
}
|
||
code {
|
||
background: #1a1a2e;
|
||
color: #5da9e9;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
}
|
||
a {
|
||
color: var(--color-highlight);
|
||
}
|
||
section.klausur {
|
||
background: #e3f2fd !important;
|
||
}
|
||
section.klausur footer {
|
||
display: none;
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
|
||
**223015b** · Modul "Technik 1" · 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
**Wintersemester 2025/26**
|
||
|
||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Termin 2 – 09.01.2026
|
||
## Bild-, Audio- & Videoformate
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Links: Hochauflösend
|
||
Rechts: Stark komprimiert (JPEG-Artefakte sichtbar)
|
||
Instagram-Effekt
|
||
-->
|
||
|
||
---
|
||
|
||
# Was ist ein Bild?
|
||
|
||
**Digital = Pixelraster**
|
||
|
||
**Beispiel: 1920×1080 (Full HD)**
|
||
= 2.073.600 Pixel
|
||
|
||
**Jedes Pixel = 3 Bytes (RGB)**
|
||
2.073.600 × 3 = **6,2 MB**
|
||
|
||
**Für EIN Foto!**
|
||
|
||
<!--
|
||
Zoom auf Pixel-Ebene zeigen
|
||
Jedes Pixel = RGB-Tripel (3 Bytes)
|
||
6 MB × 10.000 Fotos = 62 GB
|
||
Smartphone-Speicher wäre schnell voll ohne Kompression
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Rastergrafiken (Bitmaps)
|
||
|
||
**Aufbau:** 2D-Array von Pixeln mit Farbwerten
|
||
|
||
**Speicherbedarf (unkomprimiert):**
|
||
Breite × Höhe × Farbtiefe (in Bytes)
|
||
→ 1920×1080 × 3 Byte (RGB) = **6,2 MB**
|
||
|
||
**Farbtiefe:**
|
||
- 1 Bit = 2 Farben (S/W)
|
||
- 8 Bit = 256 Farben (Graustufen/Palette)
|
||
- 24 Bit = 16,7 Mio. Farben (True Color)
|
||
- 32 Bit = True Color + Alpha (Transparenz)
|
||
|
||
**Skalierung:** Interpolation (Nearest Neighbor, Bilinear, Bicubic)
|
||
|
||
<!--
|
||
DEFINITION: Bitmap = Bit-mapped graphics, 2D-Matrix aus Pixeln
|
||
BERECHNUNG SPEICHERBEDARF: 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 (Schwarz/Weiß, Fax)
|
||
- 8 Bit: 2^8 = 256 Farben (GIF, Graustufen)
|
||
- 24 Bit: 2^24 = 16.777.216 Farben (True Color, RGB je 8 Bit)
|
||
- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal (Transparenz)
|
||
INTERPOLATION bei Skalierung:
|
||
- Nearest Neighbor: Schnell, pixelig (Pixel-Art)
|
||
- Bilinear: Mittelwert aus 4 Nachbarn (Standard)
|
||
- Bicubic: 16 Nachbarn, glatter (Photoshop-Standard)
|
||
- Lanczos: Beste Qualität, rechenintensiv
|
||
PRÜFUNGSRELEVANT: Speicherberechnung, Farbtiefe-Tabelle, warum Vergrößern problematisch
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Vektorgrafiken
|
||
|
||
**Speicherung als geometrische Primitive:**
|
||
- Pfade (Bézierkurven mit Kontrollpunkten)
|
||
- Grundformen (Rechteck, Ellipse, Polygon)
|
||
- Text (Glyphen als Outlines)
|
||
|
||
**SVG-Beispiel:**
|
||
`<circle cx="50" cy="50" r="40" fill="#ff0000"/>`
|
||
→ 3 Parameter statt 5.027 Pixel (r=40)
|
||
|
||
**Rendering-Pipeline:**
|
||
Vektordaten → Rasterisierung → Framebuffer → Display
|
||
|
||
**Auflösungsunabhängig:** Gleiche Datei für Icon (32px) und Plakat (3m)
|
||
|
||
<!--
|
||
PRIMITIVE: Grundbausteine der Vektorgrafik
|
||
- Pfade: Sequenz von Punkten, verbunden durch Linien/Kurven
|
||
- Bézierkurven: Quadratisch (3 Kontrollpunkte), Kubisch (4 Kontrollpunkte)
|
||
- Formen: Rechteck, Ellipse, Polygon (intern als Pfade)
|
||
SVG-SYNTAX Beispiele:
|
||
- <rect x="0" y="0" width="100" height="50"/>
|
||
- <circle cx="50" cy="50" r="25"/>
|
||
- <path d="M 0 0 L 100 100"/> (MoveTo, LineTo)
|
||
BERECHNUNG: Kreis mit r=40 → Fläche = π×40² ≈ 5.027 Pixel vs. 3 Parameter
|
||
RENDERING-PIPELINE: Vector → Tessellation → Rasterization → Framebuffer
|
||
FORMATE:
|
||
- SVG: XML-basiert, Web-Standard, editierbar
|
||
- PDF: Seiten-Beschreibungssprache, Vektoren + Raster gemischt
|
||
- AI/EPS: Adobe-proprietär, Druckvorstufe
|
||
PRÜFUNGSRELEVANT: Warum Vektoren skalierbar, SVG-Grundsyntax, Rendering-Pipeline
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Raster vs. Vektor: Entscheidungskriterien
|
||
|
||
| Kriterium | Raster | Vektor |
|
||
|---|---|---|
|
||
| **Speicherung** | Pixelmatrix | Geometrie + Attribute |
|
||
| **Skalierung** | Qualitätsverlust | Verlustfrei |
|
||
| **Komplexität** | O(Breite × Höhe) | O(Anzahl Objekte) |
|
||
| **Bearbeitung** | Pixelbasiert | Objektbasiert |
|
||
|
||
**Wann Raster?** Fotos, Texturen, komplexe Farbverläufe
|
||
**Wann Vektor?** Logos, Icons, Typografie, technische Zeichnungen
|
||
|
||
**Konvertierung:**
|
||
- Raster → Vektor: Tracing (verlustbehaftet, approximiert)
|
||
- Vektor → Raster: Rasterisierung (exakt, aber auflösungsgebunden)
|
||
|
||
<!--
|
||
KOMPLEXITÄT erklärt:
|
||
- Raster O(w×h): Speicher wächst mit Pixelanzahl
|
||
- Vektor O(n): Speicher wächst mit Objektanzahl
|
||
BEISPIEL: Foto einer Wiese
|
||
- Raster: 1920×1080 = 2 Mio. Pixel, komprimiert ~500 KB
|
||
- Vektor: Jeder Grashalm ein Pfad → Millionen Objekte, unkomprimierbar
|
||
KONVERTIERUNG:
|
||
- Raster→Vektor (Tracing): Kantenerkennung, verlustbehaftet
|
||
- Tools: Potrace (Open Source), Adobe Live Trace, Inkscape
|
||
- Funktioniert gut: Logos, Zeichnungen, Text
|
||
- Funktioniert schlecht: Fotos, Farbverläufe
|
||
- Vektor→Raster (Rasterisierung): Exakt, aber Auflösung fixiert
|
||
- Jeder Bildschirm macht das (GPU)
|
||
- Export: "Auflösung" wählen = Ziel-Pixelgröße
|
||
ENTSCHEIDUNGSBAUM:
|
||
- Foto/Screenshot? → Raster
|
||
- Logo/Icon/Diagramm? → Vektor
|
||
- Druckvorlage? → Vektor (Auflösungsunabhängig)
|
||
- Web-Animation? → SVG (Vektor) oder Video (Raster)
|
||
PRÜFUNGSRELEVANT: Wann welches Format, Konvertierungsrichtungen und deren Eigenschaften
|
||
-->
|
||
|
||
---
|
||
|
||
# Lossless: PNG
|
||
|
||
**PNG = Portable Network Graphics (1996)**
|
||
|
||
**Funktionsweise:**
|
||
- Vorhersage (Pixel ähneln Nachbarn)
|
||
- Differenz-Encoding
|
||
- DEFLATE-Algorithmus (wie ZIP)
|
||
|
||
**Kompression:** 20-50% Ersparnis
|
||
|
||
**Gut für:** Screenshots, Logos, Text
|
||
**Schlecht für:** Fotos
|
||
|
||
<!--
|
||
PNG wurde entwickelt als GIF-Alternative (Patent-Probleme)
|
||
Lossless: Originaldaten bleiben erhalten
|
||
Transparenz: Alpha-Kanal (sanfte Übergänge)
|
||
DEFLATE: Gleicher Algorithmus wie ZIP
|
||
-->
|
||
|
||
---
|
||
|
||
# Lossy: JPEG
|
||
|
||
**JPEG = Joint Photographic Experts Group (1992)**
|
||
|
||
**Eigenschaften:**
|
||
- Lossy Kompression
|
||
- 90%+ Platzersparnis möglich
|
||
- Artefakte bei hoher Kompression
|
||
|
||
**6 MB → 500 KB** (typisch)
|
||
|
||
<!--
|
||
JPEG-Norm beschreibt nur Kompression, nicht Speicherformat
|
||
JFIF = JPEG File Interchange Format (das eigentliche Dateiformat)
|
||
Dateierweiterungen: .jpg, .jpeg, .jfif (alle gleich)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Beispiel: Stark komprimiertes JPEG
|
||
Blocking (8×8-Blöcke sichtbar)
|
||
Ringing (Geister um Kanten)
|
||
Color Banding (Verläufe "treppig")
|
||
-->
|
||
|
||
---
|
||
|
||
# Wie funktioniert JPEG? (1/2)
|
||
|
||
**Schritt 1: RGB → YCbCr**
|
||
- Y = Helligkeit (Luminanz)
|
||
- Cb/Cr = Farbe (Chrominanz)
|
||
|
||
**Warum?** Menschen sehen Helligkeit besser als Farbe
|
||
|
||
**Schritt 2: Chroma Subsampling**
|
||
Farbauflösung reduzieren (4:2:0)
|
||
→ 50% Datenmenge weg, kaum sichtbar
|
||
|
||
<!--
|
||
YCbCr = Farbraum-Konversion
|
||
Y = Brightness, Cb = Blue-Yellow, Cr = Red-Green
|
||
4:2:0 Subsampling: Farbe nur jedes 2. Pixel horizontal & vertikal
|
||
Auge merkt's kaum, weil Helligkeitssehen dominiert
|
||
-->
|
||
|
||
---
|
||
|
||
# Wie funktioniert JPEG? (2/2)
|
||
|
||
**Schritt 3: DCT (Discrete Cosine Transform)**
|
||
Bild in 8×8-Blöcke → Frequenzspektrum
|
||
|
||
**Schritt 4: Quantisierung**
|
||
Hohe Frequenzen (Details) stark reduzieren
|
||
→ **Hier passiert Datenverlust!**
|
||
|
||
**Schritt 5: Huffman-Coding**
|
||
Lossless-Kompression der Restdaten
|
||
|
||
<!--
|
||
DCT: Ähnlich wie FFT bei Audio
|
||
8×8 Blöcke: Warum JPEG "blocky" wird bei hoher Kompression
|
||
Quantisierung: Quality-Schieberegler steuert genau das
|
||
Huffman: Finale Effizienz (wie bei MP3)
|
||
-->
|
||
|
||
---
|
||
|
||
# JPEG Quality
|
||
|
||
| Quality | Dateigröße | Artefakte |
|
||
|---------|------------|-----------|
|
||
| **100** | ≈2-3 MB | Kaum |
|
||
| **85-90** | ≈200-400 KB | Minimal |
|
||
| **50** | ≈100 KB | Sichtbar |
|
||
|
||
**Sweet Spot: 85-90**
|
||
10x Kompression, für Menschen kaum unterscheidbar
|
||
|
||
<!--
|
||
Quality 100 = Minimum Compression (nicht lossless!)
|
||
Quality 85-90 = Standard für Web
|
||
Quality 50 = Sichtbare Artefakte (Blocking, Ringing)
|
||
Photoshop "Save for Web": Standard ist 60
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
GIF-Animation (z.B. Meme)
|
||
256 Farben, aber Animationen möglich
|
||
-->
|
||
|
||
---
|
||
|
||
# Die GIF-Geschichte
|
||
|
||
**GIF = Graphics Interchange Format (1987)**
|
||
CompuServe (US-Online-Dienst)
|
||
|
||
**Features:**
|
||
- 256 Farben max (8-bit Palette)
|
||
- Lossless (für Palette)
|
||
- Animationen!
|
||
|
||
**1994 Twist:** Unisys hält Patent auf LZW-Kompression
|
||
→ Fordert Lizenzgebühren
|
||
|
||
→ **"Burn All GIFs!" Kampagne**
|
||
|
||
<!--
|
||
CompuServe: Früher Online-Dienst (1969-2009)
|
||
LZW = Lempel-Ziv-Welch Compression
|
||
Unisys Patent-Trolling: Erst Jahre nach GIF-Einführung
|
||
Community-Reaktion: Boykott, Suche nach Alternative
|
||
Ergebnis: PNG wurde entwickelt (1996)
|
||
-->
|
||
|
||
---
|
||
|
||
# PNG vs. GIF
|
||
|
||
**GIF:**
|
||
✓ Animationen
|
||
✓ Breite Unterstützung
|
||
❌ Nur 256 Farben
|
||
❌ Patent-Probleme (bis 2003)
|
||
|
||
**PNG:**
|
||
✓ Millionen Farben
|
||
✓ Alpha-Transparenz
|
||
✓ Patent-frei
|
||
❌ Keine Animationen (bis APNG, 2004)
|
||
|
||
**Ergebnis:** PNG für Grafiken, GIF für Memes!
|
||
|
||
<!--
|
||
APNG = Animated PNG (Firefox, Safari support)
|
||
WebP (Google, 2010): Animationen + bessere Kompression
|
||
GIF überlebte kulturell (Meme-Format)
|
||
"GIF" Aussprache: "Jif" vs. "Gif" – ewiger Streit
|
||
-->
|
||
|
||
---
|
||
|
||
# WebP & AVIF
|
||
|
||
**WebP (Google, 2010):**
|
||
- Lossy UND Lossless
|
||
- Animationen
|
||
- 25-35% kleiner als JPEG
|
||
|
||
**AVIF (2019):**
|
||
- Basiert auf AV1-Video-Codec
|
||
- 50% kleiner als JPEG
|
||
- HDR-Unterstützung
|
||
- Patent-frei
|
||
|
||
<!--
|
||
WebP: Von Google entwickelt, deshalb Skepsis
|
||
AVIF: Alliance for Open Media (Google, Netflix, Amazon, Mozilla...)
|
||
Browser-Support 2024: WebP fast überall, AVIF wachsend
|
||
JPEG bleibt dominant (Kompatibilität!)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Vorher/Nachher: Hochauflösend vs. Instagram-Upload
|
||
Sichtbare Qualitätsverluste
|
||
-->
|
||
|
||
---
|
||
|
||
# Warum Instagram eure Fotos "ruiniert"
|
||
|
||
**Upload-Pipeline:**
|
||
1. Dein Foto: 12 MP, 8 MB
|
||
2. Instagram skaliert: max. 1080px
|
||
3. Re-Kompression: JPEG Quality ~75
|
||
4. Endgröße: 200-400 KB
|
||
|
||
**Warum?**
|
||
- Speicherkosten (Milliarden Fotos!)
|
||
- Ladezeiten (Mobile)
|
||
- Bandbreite (günstiger)
|
||
|
||
<!--
|
||
Instagram ist keine Kunstgalerie
|
||
Optimiert für Geschwindigkeit, nicht Qualität
|
||
Facebook macht dasselbe
|
||
Lösung: Portfolio-Websites (eigene Kontrolle)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Hands-On: Kompression vergleichen
|
||
|
||
**Aufgabe (40 Min):**
|
||
|
||
1. Hochauflösendes Foto (eigenes oder CC)
|
||
2. Exportiere:
|
||
- PNG
|
||
- JPEG Q100, Q85, Q50
|
||
- WebP (optional)
|
||
3. Tool: **[Squoosh.app](https://squoosh.app)** (Google-Tool)
|
||
4. Vergleiche: Dateigrößen, sichtbare Unterschiede
|
||
5. Wo werden Artefakte sichtbar?
|
||
|
||
<!--
|
||
Squoosh.app: Browser-basiert, keine Installation
|
||
Side-by-Side-Vergleich mit Zoom
|
||
Verschiedene Codecs testen
|
||
Studis sollen selbst "Sweet Spot" finden
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Video
|
||
## Kompression & Codecs
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Netflix 4K-Streaming
|
||
Unmöglich ohne moderne Codecs
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Problem: Videos sind RIIIIIIIESIG
|
||
|
||
**1 Minute 4K-Video (3840×2160):**
|
||
|
||
- 30 fps (Bilder/Sekunde)
|
||
- Jedes Bild: 24,8 MB (unkomprimiert)
|
||
|
||
**Rechnung:**
|
||
30 × 24,8 MB = **744 MB/Sekunde**
|
||
× 60 Sekunden = **44,6 GB/Minute**
|
||
|
||
**2-Stunden-Film: 5,3 TB!**
|
||
|
||
<!--
|
||
4K = 3840×2160 Pixel = 8,3 Megapixel pro Frame
|
||
30 fps = Standard, Kino = 24 fps, Gaming = 60+ fps
|
||
Ohne Kompression: Unmöglich zu streamen oder speichern
|
||
-->
|
||
|
||
---
|
||
|
||
# Container vs. Codec
|
||
|
||
**Container = Die Box**
|
||
Verpackt Video, Audio, Untertitel, Metadaten
|
||
|
||
**Beispiele:** MP4, MKV, AVI, MOV
|
||
|
||
**Codec = Kompressionsalgorithmus**
|
||
Entscheidet, WIE Daten komprimiert werden
|
||
|
||
**Video-Codecs:** H.264, H.265, VP9, AV1
|
||
**Audio-Codecs:** AAC, MP3, Opus
|
||
|
||
<!--
|
||
Container ≠ Codec (häufiges Missverständnis!)
|
||
MP4 ist KEIN Codec, sondern Container
|
||
Schachtel-Analogie: Container = Karton, Codec = Inhalt
|
||
Ein MP4 kann H.264, H.265 oder AV1 enthalten
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Diagramm: Container mit verschiedenen Streams
|
||
Video-Track (H.264)
|
||
Audio-Track (AAC)
|
||
Untertitel-Track (SRT)
|
||
Metadaten (Titel, Künstler, etc.)
|
||
-->
|
||
|
||
---
|
||
|
||
# Video-Kompression: Drei Prinzipien
|
||
|
||
**1. Spatial Compression (Intra-Frame)**
|
||
Jedes Bild einzeln (wie JPEG)
|
||
→ I-Frames
|
||
|
||
**2. Temporal Compression (Inter-Frame)**
|
||
Nur Änderungen zwischen Bildern
|
||
→ P-Frames, B-Frames
|
||
|
||
**3. Motion Compensation**
|
||
"Ball bewegt sich von A nach B"
|
||
|
||
<!--
|
||
Spatial: Innerhalb eines Bildes (JPEG-ähnlich)
|
||
Temporal: Zwischen Bildern (zeitliche Redundanz)
|
||
Motion Compensation: Intelligente Vorhersage
|
||
→ 90%+ Effizienz durch temporale Kompression
|
||
-->
|
||
|
||
---
|
||
|
||
# I-Frames, P-Frames, B-Frames
|
||
|
||
**I-Frame (Intra):**
|
||
Vollständiges Bild (wie JPEG)
|
||
Groß, aber unabhängig
|
||
|
||
**P-Frame (Predicted):**
|
||
Referenziert vorherige Frames
|
||
Viel kleiner
|
||
|
||
**B-Frame (Bi-directional):**
|
||
Referenziert vorherige UND zukünftige Frames
|
||
Am effizientesten
|
||
|
||
**GOP:** I - B - B - P - B - B - P - B - B - I
|
||
|
||
<!--
|
||
GOP = Group of Pictures (typisch 12-15 Frames)
|
||
I-Frame: Alle 1-2 Sekunden nötig (für Seeking)
|
||
P-Frame: "Pixel X bewegt sich 5px rechts"
|
||
B-Frame: Komplex, aber beste Kompression
|
||
Wenn du vorspulst: Sucht nach nächstem I-Frame
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Visualisierung: I/P/B-Frame-Abhängigkeiten
|
||
I-Frame = Vollbild (Keyframe), P/B-Frames speichern nur Unterschiede
|
||
Quelle: https://www.canon.com.hk/cpx/en/technical/va_EOS_Movie_Compression_Options_All_I_and_IPB.html
|
||
-->
|
||
|
||
---
|
||
|
||
# H.264: Der König
|
||
|
||
**H.264 / AVC (2003)**
|
||
|
||
**Warum dominant?**
|
||
✓ Exzellente Kompression (100:1 möglich)
|
||
✓ Hardware-Support (jedes Gerät seit ~2010)
|
||
✓ YouTube, Netflix, Blu-ray – alles H.264
|
||
|
||
**Features:**
|
||
- Variable Block-Größen (16×16 bis 4×4)
|
||
- Deblocking-Filter
|
||
- CABAC-Coding
|
||
|
||
<!--
|
||
AVC = Advanced Video Coding
|
||
MPEG-4 Part 10 = H.264 (gleicher Standard)
|
||
Revolutionierte Video-Streaming
|
||
Hardware-Decoder in CPUs/GPUs → Batterie-schonend
|
||
CABAC = Context-Adaptive Binary Arithmetic Coding
|
||
-->
|
||
|
||
---
|
||
|
||
# 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/Einheit
|
||
- Content-Distribution: Kostenlos für "Internet Broadcast"
|
||
|
||
**Problem:** Open-Source-Projekte in Grauzone
|
||
|
||
<!--
|
||
MPEG-LA = Licensing Authority
|
||
Firefox weigerte sich lange, H.264 zu supporten (Patent-Gründe)
|
||
Chromium musste extern linken
|
||
Patent-Pool: Firmen teilen Patente, gemeinsame Lizenzierung
|
||
"Free to View" Klausel: YouTube etc. kostenlos
|
||
-->
|
||
|
||
---
|
||
|
||
# H.265 / HEVC
|
||
|
||
**H.265 (2013):**
|
||
50% bessere Kompression als H.264
|
||
|
||
**ABER:** Patent-Desaster
|
||
|
||
**Drei (!) konkurrierende Patent-Pools:**
|
||
- MPEG-LA
|
||
- HEVC Advance
|
||
- Velos Media
|
||
|
||
→ Viele bleiben bei H.264 oder suchen Alternativen
|
||
|
||
<!--
|
||
HEVC = High Efficiency Video Coding
|
||
Technisch überlegen, aber juristisch Albtraum
|
||
Apple nutzt HEVC (iPhone-Videos)
|
||
Netflix zögert wegen Lizenzkosten
|
||
Fragmentierung verzögert Adoption
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
YouTube VP9-Logo
|
||
Google's Patent-freie Alternative
|
||
-->
|
||
|
||
---
|
||
|
||
# VP9: Googles Antwort
|
||
|
||
**VP9 (2013):**
|
||
Entwickelt von Google (On2-Akquisition)
|
||
|
||
**Eigenschaften:**
|
||
✓ Ähnlich H.265-Kompression
|
||
✓ KOSTENLOS, patent-frei (laut Google)
|
||
✓ YouTube nutzt VP9 für 4K
|
||
|
||
**Nachteile:**
|
||
❌ Hardware-Support langsam
|
||
❌ Höherer CPU-Aufwand
|
||
❌ Nicht universell wie H.264
|
||
|
||
<!--
|
||
On2 Technologies: Gekauft 2010 für $133M
|
||
VP8 → VP9 → AV1 (Evolution)
|
||
YouTube forciert VP9: 4K-Videos nur VP9/AV1
|
||
Hardware-Decoder erst ab ~2016 (langsame Adoption)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
AV1-Logo
|
||
Alliance for Open Media
|
||
-->
|
||
|
||
---
|
||
|
||
# AV1: Die Open-Source-Revolution
|
||
|
||
**AV1 (2018):**
|
||
Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
|
||
|
||
**Ziel:** Patent-freier, moderner Codec
|
||
|
||
**Features:**
|
||
✓ 30% besser als H.265
|
||
✓ Royalty-free, Open Source
|
||
✓ 8K, HDR, hohe Frame-Rates
|
||
|
||
**Stand 2025:**
|
||
YouTube, Netflix nutzen AV1 für 4K/8K
|
||
|
||
<!--
|
||
AOM = Alliance for Open Media (2015 gegründet)
|
||
Alle Big-Tech-Player vereint (historisch!)
|
||
"Fuck you" an Patent-Mafia
|
||
Problem: Encoding SEHR langsam (10-100x vs. H.264)
|
||
Hardware-Encoder kommen (ab 2020er-GPUs)
|
||
-->
|
||
|
||
---
|
||
|
||
# Adaptive Bitrate Streaming
|
||
|
||
**Problem:** Internet-Geschwindigkeit variiert
|
||
|
||
**Lösung:** Mehrere Qualitäten parallel
|
||
|
||
**MPEG-DASH / HLS:**
|
||
- 4K (20 Mbps)
|
||
- 1080p (5 Mbps)
|
||
- 720p (2,5 Mbps)
|
||
- 480p (1 Mbps)
|
||
- 240p (0,5 Mbps)
|
||
|
||
Segmente: 2-10 Sekunden (Player wählt dynamisch)
|
||
|
||
<!--
|
||
DASH = Dynamic Adaptive Streaming over HTTP
|
||
HLS = HTTP Live Streaming (Apple)
|
||
Beide ähnlich, aber inkompatibel
|
||
Manifest-Datei: Liste aller Qualitäten
|
||
Player misst Bandbreite, wechselt live
|
||
→ Warum Netflix plötzlich pixelig wird
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Visualisierung: Qualitätswechsel während Playback
|
||
Bandbreite schwankt → Player reagiert
|
||
-->
|
||
|
||
---
|
||
|
||
# Container im Detail
|
||
|
||
**MP4:** Standard für Web/Mobile, DRM-fähig (H.264, H.265, AV1)
|
||
|
||
**MKV:** Open Source, beliebig viele Spuren (fast jeder Codec)
|
||
|
||
**WebM:** Google/Web-optimiert (nur VP9/AV1 + Opus/Vorbis)
|
||
|
||
<!--
|
||
MP4 = MPEG-4 Part 14 (ISO-Standard)
|
||
Matroska = Russisch: Matrjoschka (Puppen ineinander)
|
||
WebM = Subset von Matroska (HTML5-Video)
|
||
MKV vs. MP4: Offenheit vs. Kompatibilität
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: Video analysieren
|
||
|
||
**Aufgabe (40 Min):**
|
||
|
||
**Tools:**
|
||
- Desktop: FFmpeg, HandBrake, [MediaInfo](https://mediaarea.net/MediaInfoOnline)
|
||
- Browser: [Squoosh.app](https://squoosh.app) (Bilder), [MediaInfo Online](https://mediaarea.net/MediaInfoOnline)
|
||
- iOS/Android: MediaInfo App, VLC
|
||
|
||
1. Download: CC-Video (Big Buck Bunny, ~1 Min)
|
||
2. Analysiere: Container, Codec, Bitrate, Auflösung
|
||
3. Konvertiere: H.264 vs. H.265 (gleiche Qualität)
|
||
4. Vergleiche: Größen, Encoding-Zeit
|
||
|
||
<!--
|
||
Big Buck Bunny: Open-Source-Film (Blender Foundation)
|
||
FFmpeg: Swiss Army Knife für Video
|
||
HandBrake: GUI für FFmpeg (einfacher)
|
||
MediaInfo: Detaillierte Datei-Analyse
|
||
Encoding-Zeit: H.265 deutlich langsamer als H.264
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** mail@librete.ch
|
||
**Folien:** Online verfügbar unter 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: https://creativecommons.org/licenses/by-sa/4.0/
|
||
|